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 to master
   • (oid, version) predicates
   • writes, creates (server-assigned keys?), deletes
   • reads?
2. Master writes transaction object with list of participants, acquiring a txid
3. Master sends txid, MT to all participants
4. Participants lock objects and log MT
5. Participants send vote
6. Master writes decision in table
7. Master relays decision to participants
8. Master relays to client
9. Participants commit
10. Participants acknowledge
11. Master removes transaction object