[rucksack-devel] Transactions: abort early?

Arthur Lemmens alemmens at xs4all.nl
Mon May 22 19:32:47 UTC 2006


Nikodemus wrote:

>  Transaction T1 starts.
>  T1 does stuff, but doesn't read or write object O.
>  Transaction T2 starts.
>  T2 touches O.
>  T2 commits.
>  T1 reads 0.
>
> Option 1b:
>
>  * We no longer have access to O that matches the rest of the T1.
>    Abort T1 immediately.
>
> If I understand correctly two-phase locking comes down to this,
> actually.

I don't think so.  As far as I understand it, the basic idea of two-phase
locking is that a transaction should acquire a shared (read-only) lock for
every object it wants to read and an exclusive (read/write) lock for each
object it wants to change.  And it may not release those locks until it
commits.  (It's called two-phase because there's a phase when it only acquires
locks and a phase where it releases locks, and those two phases may not
interleave.)

So I think your scenario would go like this:

1.  T1 starts: not really relevant
2.  T1 does stuff, but doesn't read or write object O: not relevant
3.  T2 starts: not relevant
4a. T2 aquires an exclusive lock on O
4b. T2 writes O
5.  T2 commits, releasing the exclusive lock on O
6a. T1 acquires a shared lock on O
6b. T1 reads O.

I don't think there's a problem here.  T1 is now free to change O and/or
commit, and there still won't be a problem.

But maybe I'm missing something?

Arthur




More information about the rucksack-devel mailing list