A transaction is a set of operations that should happen atomically. Exactly which operations that may include is up for discussion, but think reads, writes, deletes, and possibly index lookups for now.

Client-Side Transactions

1. Client reads A, B, C
2. Client reserves txid
3. Client writes A, B, C with lien to txid for some time (how long? see below)
4. Client writes T with (A', B', C') at txid
5. Client writes A' into A, B' into B, C' into C
6. Client deletes T

Consequences:

• A, B, C appear an extra time in the log with the liens.
• A', B', C' appear twice in the log.
• Client clocks must be synchronized
• The objects in a transaction should have lien expiry times larger than the time it takes to recover a server: this could be a relatively long time. If the client crashes (instead of a server), the objects involved must stay locked until the lien expires.
• Blind (unconditional) updates, deletes, and creates are no longer possible as the objects they operate on may have liens.
• Can only support creates using server-assigned object IDs if it is acceptable to burn object IDs when clients crash.

Server-Side Transactions (2PC)

1. Client sends MT ("minitransaction") to master
   • predicates: list of (table id, oid, version)
     • If the transaction commits, the object must have the given version at the time the decision is made. If the object has some other operation applied to it below, it must additionally not be modified until the operation is applied.
   • writes: list of (table id, oid, data, indexes)
     • If the transaction commits, the data and index entries will be stored in the object.
   • creates (with server-assigned keys): list of (table, data, indexes)
     • If the transaction commits, the data and index entries will be stored in a new object.
       • How will the client get to know which object this is? Either the master will have to delay returning the outcome to the client or the participant will have to allocate the ID before the decision to commit is made.
   • deletes: list of (table id, oid)
     • If the transaction commits, the object will be deleted.
   • reads: list of (table id, oid)
     • If the transaction commits, the data and index entries will be returned.
     • Doing reads outside the transaction and then sending a transaction consisting of predicates for the versions that were read is the optimistic alternative to this. Do we want to support pessimistic reads inside transactions?
2. Master writes transaction object with list of participants, acquiring a txid
3. Master sends txid, MT to all participants
   • By sending the txid and MT, the master guarantees to send the participants a decision eventually.
4. Participants lock objects and log MT
5. Participants send vote to master
   • By casting their vote, they guarantee to keep their objects locked until they learn the decision.
   • If they vote yes, they guarantee to be able to commit if that is the decision (i.e., they persist the intent of the MT).
6. Master writes decision in table
7. Master relays decision to participants
8. Master sends response to client
9. Participants commit
10. Participants sends commit acknowledgement to master
    • By sending their commit acknowledgement, they guarantee to never ask the master about txid again.
11. Master removes transaction object