Re: Serializable Snapshot Isolation

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

Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)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 serializable transaction
* when that write would have been visible had the writing
* transaction committed before the start of 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. Predicate locks are used for this.
* Detection of such a conflict does not cause blocking, and does
* not, in itself, cause a 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 another transaction). In addition, the transaction on
* the "out" side of the pivot must commit first, and if the
* transaction on 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