Re: Serializable Snapshot Isolation

I've been thinking about these points, and reconsidered somewhat.

Heikki Linnakangas <heikki.linnakangas@enterprisedb.com> wrote:
> Should add a citation to Cahill's work this is based on.
> Preferably with a hyperlink.
I've been thinking that this should be mentioned in both the README
and the source code.
> A short description of how the predicate locks help to implement
> serializable mode would be nice too.  I haven't read Cahill's
> papers, and I'm left wondering what the RW conflicts and
> dependencies are, when you're supposed to grab predicate locks
> etc.
Again -- why be stingy?  Given a more complete README file, how
about something like?:
/** A rw-conflict occurs when a read by one serializable transaction* does not see the write of a concurrent
serializabletransaction* when that write would have been visible had the writing* transaction committed before the
startof the reading* transaction. When the write occurs first, the read can detect* this conflict by examining the MVCC
information. When the read* occurs first, it must record this somewhere so that writes can* check for a conflict.
Predicatelocks are used for this. * Detection of such a conflict does not cause blocking, and does* not, in itself,
causea transaction rollback.** Transaction rollback is required when one transaction (called a* "pivot") has a
rw-conflict*in* (a concurrent transaction* couldn't see its write) as well as *out* (it couldn't see the* write of
anothertransaction).  In addition, the transaction on* the "out" side of the pivot must commit first, and if the*
transactionon the "in" side of the pivot is read-only, it must* acquire its snapshot after the successful commit of
the*transaction on the "out" side of the pivot.*/
 
Would something like that have helped?
-Kevin