[rucksack-devel] Re: Rucksack, ECLM

[Arthur Lemmens]

Nikodemus wrote:

>> No, with my multiple versioning scheme this is not true.  The
>> important point here is that it does not (and should not) make any
>> difference whether A has committed or not.  The only difference
>> between a committed transaction and an 'open' (not yet committed)
>> transaction is that you can be sure that the committed transaction
>> has written its changes to disk.
>
> So in Rucksack transactions are about consistency and durability, not
> isolation and atomicity?

I'm not totally sure why you put it like that.  Let me try to explain
what I expect from transactions:

- Once a transaction has committed, you should have a guarantee that
   your changes are made persistent: when you reboot Rucksack after
   a commit, it should find all chose changes.  That's the durability
   part.

- Transactions should be all-or-nothing.  If an error occurs during a
   transaction and a transaction is aborted (rolled back), all of the
   changes made by that transaction should be undone.  That's the
   atomicity part.

- Parallel transactions should behave as if they happened sequentially.
   They should have the same effect as if the oldest transaction has
   started and completed its job before all younger transactions.  That's
   the isolation part I think.  (Maybe it's also the consistency part;
   but it always seemed to me that consistency must be guaranteed by
   the application, not just by the persistence library.)

> Scenario 1.
>
>  A enters.
>  A increments C -> 1.
>  B enters.
>  B increments C -> 2.
>  A aborts (rollback).
>  B commits.

Good point.  I think B shouldn't be allowed to commit as is, because it
depends on a value that was modified by A.  The simplest solution seems
to be to abort B when A is aborted.  In general, we could abort a
transaction if it depends on a value that was created/modified by a
transaction that's being aborted.  I think this is doable in practice;
Rucksack already keeps track of all the information that's necessary
to do this.

This seems to be consistent with my transaction requirements above.

> Scenerio 2.
>
>  A enters.
>  A increments C -> 1.
>  B enters.
>  B increments C -> 2.
>  B commits.
>  A aborts (rollback).

This one is more problematic.  After B commits, the application should
have the guarantee that B's values won't change anymore.  But when A
aborts, the correct solution seems to be to abort B too (because B has
a value that depends on A).  The only solution I can come up with is
to prevent B from committing until A has committed.  That means it would
have to block until A has committed, but that may destroy part of the
performance advantage that we could get from multiple versioning.

Hmmm.  Do you see other options here?

Arthur