Re: Serializable transactions get rolled back while there are no othertransactions running?!

Jonathan Lewis wrote:
> Your comment leads to an interesting philosophical point -
> I execute a serializable transaction, but do NOT
> revisit row X, which gets changed and committed
> by another user in the interim.
>
> I execute the same serializable transaction, but DO
> revisit row X, which gets changed and committed
> by another user in the interim. However, there is
> nothing in my transaction that I do differently, whether
> or not I can see the change (which I couldn't in Oracle
> of course).
>
> Should either, neither, or both of those transaction fail
> according to your concept of serializable ?
>
> I think this may qualify as the "Schrödinger's Cat" of the
> serializable transaction.

This certainly is OT, but I can explain what effect this would have with 2PL done e.g. in MS SQLServer. When you have two tx called t1 and t2 in the first scenario the equivalent serial execution would be t2, t1 in the second t1, t2 as t2 would have to wait until t1 releases read locks on row X. Thus both scenatios are serializable...

Even more OT I was wondering if the definition of serializable I use (~ there must be a serial execution that has the same result) and the SQL one (dirty reads, nonrepeatable reads and phantoms must be avoided) are really equivalent. Has there been any proof.

Oliver Received on Thu Jun 24 2004 - 05:34:37 CDT