Re: Row locking and serializability

A less obvious, but perhaps more interesting serialization is the order in which transactions ENDED.
That is, the timestamp on the COMMIT. This is harder to implement, because if you assign a
unique and sequential transaction number to every transaction at its start, those transaction numbers won't give you the order I'm suggesting.

There are some interesting consequences to choosing this order.

Transaction that ended in a ROLLBACK, and READ ONLY transactions represent special cases.
You don't care about them with regard to final state of the database, buit if you wanted to
guarantee that such transactions, if repeated in serial mode would RECEIVE the same data,
now you've got something else to think about. Why would anybody care? Well, after all, this is the database THEORY forum, so maybe there's a theoretical interest somewhere.

Regards,

     Dave Cressey

Jonathan Lewis wrote in message
<928412631.17530.1.nnrp-02.9e984b29_at_news.demon.co.uk>...
>The 'obvious' sequence to choose is the sequence
>in which the transactions started, and this is what
>Oracle does.
Received on Sat Jun 05 1999 - 08:18:23 CDT