"Markus Wanner" <markus@bluegap.ch> wrote:
> What I'm more concerned is the requirement of the proposed algorithm
> to keep track of the set of tuples read by any transaction and keep
> that set until sometime well after the transaction committed (as
> questioned by Neil). That doesn't sound like a negligible overhead.
Quick summary for those who haven't read the paper: with this
non-blocking technique, every serializable transaction which
successfully commits must have its read locks tracked until all
serializable transactions which are active at the commit also
complete.
In the prototype implementation, I think they periodically scanned to
drop old transactions, and also did a final check right before
deciding there is a conflict which requires rollback, cleaning up the
transaction if it had terminated after the last scan but in time to
prevent a problem.
-Kevin