Re: incoherent view of serializable transactions

>>> Emmanuel Cecchet <manu(at)frogthinker(dot)org> 12/22/08 11:42 PM >>>
> If you want to know how to build SERIALIZABLE with a database that
> provides SI (Snapshot Isolation), read
> http://portal.acm.org/citation.cfm?doid=1376616.137669

The link didn't seem to work for me, but I think I found the article
you meant: "Serializable Isolation for Snapshot Databases"
by Michael J. Cahill, et al

An interesting work. If nothing else, it will help flesh out the
documentation of anomalies. If the PostgreSQL community ever
does want to better approach true serializable behavior, this
should provide a good theoretical basis.

Thanks very much for the cite.

> I still don't
> get why people would use SERIALIZABLE since there is no efficient
> implementation of it.

Read the last paragraph of the secion 1 (Introduction)
of the article you just cited.

-Kevin

Hi Kevin,

> The link didn't seem to work for me, but I think I found the article
> you meant: "Serializable Isolation for Snapshot Databases"
> by Michael J. Cahill, et al
>
> An interesting work. If nothing else, it will help flesh out the
> documentation of anomalies. If the PostgreSQL community ever
> does want to better approach true serializable behavior, this
> should provide a good theoretical basis.
>
Sorry for the broken link. Yes this is the paper.
Note that the paper was not necessarily enthusiastically received by the
community when presented at the conference. While this is an interesting
academic paper, it's practicality left a majority of the audience
perplex. There was an interesting comment by Oracle folks: Oracle does
not provide serializability but only snapshot isolation, and still users
prefer to 'downgrade' to read committed for better performance. The
Oracle guys experience seemed to indicate that there was no need for
serializability (well, that's also less work for them ;-)) in their
customer base.
Having both a foot in academia and in industry, I understand the
intellectual interest for serializability on the academic side, but I
still have not seen a single use case in industry where this was a
requirement (but my db experience is probably narrow).

Have nice serializable holidays ;-)
manu

--
Emmanuel Cecchet
FTO @ Frog Thinker
Open Source Development & Consulting
--
Web: http://www.frogthinker.org
email: manu(at)frogthinker(dot)org
Skype: emmanuel_cecchet

>>> Emmanuel Cecchet <manu(at)frogthinker(dot)org> wrote:
> There was an interesting comment by Oracle folks: Oracle does
> not provide serializability but only snapshot isolation, and still
users
> prefer to 'downgrade' to read committed for better performance. The
> Oracle guys experience seemed to indicate that there was no need for

> serializability (well, that's also less work for them ;-)) in their
> customer base.

Although I note that, while this work was done in 2006 at the
University of Sidney, Mr. Cahill is now an employee of Oracle
Corporation....

The interesting thing about this technique is that it works without
the kind of blocking which is the bane of other implementation
techniques. Reads don't block writes or vice versa. In my receipt
example, the fact that there is a transitory state where the view of
the data would not be consistent would cause no problems unless
someone actually tried to view the data within that (probably very
small) window of time.

-Kevin