[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