On 1.12.11 15:10, Jukka Zitting wrote:
If I understand the paper correctly, also this approach requires
synchronization to establish the serialization order of transactions.
No I don't think so. What it does is, it cancels problematic transactions.
Detecting these requires finding certain read-write conflicts between
transactions.
But if there are two concurrent transactions, the commit of the other
one needs to wait until the first one has been processed before it can
complete the check against conflicts. Otherwise how can a conflicting
commit be made to fail?
I see, that's right. Unless the other transaction has access to the
operations of the first transaction. In that case - and if it decides to
abort due to a conflict and later the first also decides to abort - the
other transaction would have aborted unnecessarily. That shouldn't hurt
too much though.
Michael
