[rucksack-devel] Transactions: abort early?

[Arthur Lemmens]

Nikodemus wrote:

> In doing the prevalent stuff, I've gotten to the point of fiddling with
> alternative transaction implementations:

This may sound strange coming from me, but for prevalent objects I'd
seriously consider using two-phase locking (acquire a lock for each object
when you access it and release all locks at the end of the transaction).

Two-phase locking is relatively easy to implement I think (I've never done
it).  And because prevalent transactions only use in-memory objects, they
can be *much* faster than 'persistent transactions', so the chance that
two-phase locking slows down the system to an unacceptable degree will be
much smaller than for persistent transactions.

>  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?

If you decide not to do two-phase locking, option 1b sounds good to me.
(Not that that means very much; this whole transaction implementation
business is quite new to me.)

Arthur