[rucksack-devel] Transactions: abort early?
Nikodemus Siivola
nikodemus at random-state.net
Sun May 21 11:41:12 UTC 2006
In doing the prevalent stuff, I've gotten to the point of fiddling with
alternative transaction implementations: (I'm not taking the classic
write-ahead logging route, since I think what I have is nicer and likely
to perform better).
Situtation:
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 1a:
* We no longer have access to O that matches the rest of the T1.
Let T1 read O, but make it fail on commit due to the inconsistence.
Option 1b:
* We no longer have access to O that matches the rest of the T1.
Abort T1 immediately.
Option 2:
* We _have_ a copy of O that matches T1. Let T1 read O, but make it
fail on commit as its assumptions are no longer true.
My personal preference is 1b, and I was under the impression that
aborting early was in the spirit of Rucksack generally, so I assume
this is OK?
Cheers,
-- Nikodemus Schemer: "Buddha is small, clean, and serious."
Lispnik: "Buddha is big, has hairy armpits, and laughs."
More information about the rucksack-devel
mailing list