Answer to the breakout room question: 1. Get the transaction descriptor 2. Obtain the log for obj or obj.f1 depending on the granularity. Take the lock because this is a pessimistic write. 3. Write old value into the undo log
4. Update in place (because it is eager versioning)

Yikes, that did not format

Answer to the breakout room question: 1. Get the transaction descriptor

1. Obtain the log for obj or obj.f1 depending on the granularity. Take the lock because this is a pessimistic write.

2. Write old value into the undo log

3. Update in place (because it is eager versioning)

One question people had in the chat was when are the timestamp updates? Kayvon's answer: The timestamp update is on transaction commit, not on data element write. The timestamp is like the id of the transaction that last wrote the data to memory.

I think pessimistic (eager) write means we are writing to memory so we need to acquire a lock otherwise there could be a race with other transactions. For the case of optimistic (lazy) write we would write to the write buffer so we would not need to acquire a lock.

@pslui88 I thought implementing transaction commit definitely counts as part of implementing an atomic block, which may be what others also found confusing.

Adding on to @pslui88, because the timestamps are associated with whole transactions, this fits in with the idea of transactions being "all-or-nothing" because all of the data has to be committed at the same "time" with respect to other transactions.

@blipblop Yes but it's not strictly related to a single write as shown on the slide. For example, you can have another read after the write and commit together. The timestamp is only updated after that.