The slides says eager version has problem in fault tolerance issue when there is crash in middle of transaction, but how is this related with transaction memory? I mean what is crash in memory transaction, and how it's possible to do fault tolerance.
HLAHat
I suppose a crash would cause the undo log to be wiped, but the local memory writes would be preserved. This would cause a problem if the transaction fails later on since the processor would have forgotten the initial state to roll back to. This is just a theory though, I don't actually now if that's how it works.
Corian
Eager and lazy appear to take the same time overall for a transaction, but eager has more difficulties with fault tolerance. In what case is eager versioning preferred?
vrazdan
@corian, when dealing with a large amount of writes in a transaction with a high probability of succeeding (not sure of a situation, but just assume this can happen), then eager would be better, as lazy would flush all writes at once (potentially hitting a bandwidth limit), while eager would have already done all the writes.
haodongl
@HLAHat, I agree with your theory. Since the change is already written to memory, and undo log is lost, there is no way to undo the transaction.
caretcaret
It seems that lazy versioning could benefit from spatial locality (write buffer is closer to the processor, likely in the cache, so less latency and snooping traffic) and temporal locality (fewer write requests to the same memory address if it is accessed multiple times during the transaction).
The slides says eager version has problem in fault tolerance issue when there is crash in middle of transaction, but how is this related with transaction memory? I mean what is crash in memory transaction, and how it's possible to do fault tolerance.
I suppose a crash would cause the undo log to be wiped, but the local memory writes would be preserved. This would cause a problem if the transaction fails later on since the processor would have forgotten the initial state to roll back to. This is just a theory though, I don't actually now if that's how it works.
Eager and lazy appear to take the same time overall for a transaction, but eager has more difficulties with fault tolerance. In what case is eager versioning preferred?
@corian, when dealing with a large amount of writes in a transaction with a high probability of succeeding (not sure of a situation, but just assume this can happen), then eager would be better, as lazy would flush all writes at once (potentially hitting a bandwidth limit), while eager would have already done all the writes.
@HLAHat, I agree with your theory. Since the change is already written to memory, and undo log is lost, there is no way to undo the transaction.
It seems that lazy versioning could benefit from spatial locality (write buffer is closer to the processor, likely in the cache, so less latency and snooping traffic) and temporal locality (fewer write requests to the same memory address if it is accessed multiple times during the transaction).