[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