To summarize the differences between the two, the eager version assumes that it will not have to abort so it is able to be faster by always writing directly to memory, but pays the price if a transaction needs to be rolled back. The lazy versioning on the other hand values never having to roll back so it pays the price of only writing to memory on commits when it knows that its changes are committed.
bazinga
In case of a crash in the middle of a transaction, lazy versioning easily provides isolation, whereas isolation in case of eager versioning is more difficult.
SR_94
What if lazy versioning (thread) crashed when the thread is halfway through flushing the buffer into memory on a commit, won't the memory be in an inconsistent state then?
unparalleled
SR_94, It uses WAL where a log is maintained to track the progress of the "commit" process. The Write ahead log is stored on a persistent storage, and on a crash when the system recovers, it checks the WAL to redo any pending commits.
fxffx
Eager versioning is optimistic about the transaction, and expects that transaction will not fail most of the time; Lazy versioning is pessimistic.
To summarize the differences between the two, the eager version assumes that it will not have to abort so it is able to be faster by always writing directly to memory, but pays the price if a transaction needs to be rolled back. The lazy versioning on the other hand values never having to roll back so it pays the price of only writing to memory on commits when it knows that its changes are committed.
In case of a crash in the middle of a transaction, lazy versioning easily provides isolation, whereas isolation in case of eager versioning is more difficult.
What if lazy versioning (thread) crashed when the thread is halfway through flushing the buffer into memory on a commit, won't the memory be in an inconsistent state then?
SR_94, It uses WAL where a log is maintained to track the progress of the "commit" process. The Write ahead log is stored on a persistent storage, and on a crash when the system recovers, it checks the WAL to redo any pending commits.
Eager versioning is optimistic about the transaction, and expects that transaction will not fail most of the time; Lazy versioning is pessimistic.