Multi-threaded Transactions
[Transactions, Locking and Logging]

Collaboration diagram for Multi-threaded Transactions:

Certain operations may be performed while more than one thread is attached to a transaction (this functionality is soon to be deprecated). Any number of attached threads may be read-only. The kinds of updates that can be made by multiple threads are limited by the need to avoid latch-mutex and latch-latch deadlocks.

There are several reasons for this. 1) The multiple threads are not protected from each other by locks. 2) Interleaving of top-level actions is not supported with rollback; this means that for the duration of a top-level action, a thread needs access to the log that excludes all other threads in the same transaction.

The internal logging protocol is this: T1: latch page, log update. Logging requires acquiring a mutex on the xct's log buffer. T2: performing any top-level action, acquires the mutex on the xct's log buffer before doing the action (latching the page).

Thus, anything involving top-level actions is suspect. B-trees use top-level actions, as does file-page allocation, and creation/ destruction of stores (files, indexes). Thus, just about any kind of concurrent updates on the same page in the same transaction is problematic, and just about any update can result in latching extent-map or store-map pages. This activity could be disallowed by enforcing a strict rule that at most one update operation can be going on in a transaction at any time, however this is too restrictive.

Multiple updating threads can work if the data are partitioned by volume. So a well-behaved server may use multiple-threaded transactions to do updates as long as the updates are on different volumes. It might also allow read-only transaction threads to be concurrent with a single updating thread.

Savepoints and partial rollback may not be used with multi-threaded transactions. This is not enforced by the storage manager; it is poor behavior on the part of a server. For example, the behavior of the following is undefined:

• thread 1: attach, read, read, read, ...
• thread 2: attach, save work, update, rollback If the two threads are reading and possibly updating the same data, the results are timing-dependent and could produce a latch- latch or latch-mutex deadlock.

Ongoing research at DIAS is investigating ways to extend the usefulness of parallelism within a transaction (multi-threaded transactions). Current thoughts about this are for servers to coordinate multiple transactions using two-phase commit or an optimized version of commit and abort for groups of local transactions.

---