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
- Client reads A, B, C
- Client reserves txid
- Client writes A, B, C with lien to txid for some time (how long? see below)
- Client writes T with (A', B', C') at txid
- Client writes A' into A, B' into B, C' into C
- 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)
- Client sends MT to master
- (oid, version) predicates
- writes, creates (server-assigned keys?), deletes
- reads?
- Master writes transaction object with list of participants, acquiring a txid
- Master sends txid, MT to all participants
- Participants lock objects and log MT
- Participants send vote
- Master writes decision in table
- Master relays decision to participants
- Master relays to client
- Participants commit
- Participants acknowledge
- Master removes transaction object