Re: Row locking and serializability

Oops, while the main point didn't change, a correction is requred. Actually, after A and B both have read the data, optimistic method (first-committer-wins) is applied. A would be allowed to write the change, and B would not. Then one of two scenarious is possible: B could either be aborted, or restarted with new timestamp -- could anybody clarify on that, please?

Vadim Tropashko wrote:

> Iggy,
>
> I don't see how your airline booking example works. In time domain
> addressing aproach (i believe it's the same thing as "snapshot" isolation
> approach taken by Oracle since release 7.3) the database record history is
> divided into time intervals:
> <98,[t0,t1)>, <99,[t1,*)>
> In other words, at time t0 passenger count has been updated to 98, and
> later, at time t1 the most recent update - count=99 - has been made. That is
> the current value.
>
> Each transaction is assigned a time at which it begins. In your example,
> transaction A at time t2 (excuse me for shifting your timeline by 2:-)
> modifies the history like this:
> <98,[t0,t1)>, <99,[t1,t2)>, <99,[t2,*)>
> As you see, even though the count value didn't change, the history is
> extended to the present.
> Next transaction B reads the count and, therefore, modifies history into:
> <98,[t0,t1)>, <99,[t1,t2)>, <99,[t2,t3)>, <99,[t3,*)>
> Now transaction A runs in the past and cannot update the count (while B
> still can!).
>
Received on Mon Jun 14 1999 - 21:12:53 CDT