[rucksack-devel] Re: Rucksack, ECLM

[Nikodemus Siivola]

"Arthur Lemmens" <alemmens at xs4all.nl> writes:

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

Right. Fits my expectations too.

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

> This seems to be consistent with my transaction requirements above.

Right.

>> 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 would work, I think. 

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

What if transaction were allowed to choose the isolation level they
wanted?

 a) Uncommited changes from other transactions visible. The moment B
    sees an uncommitted change from A the transactions it becomes
    dependent on it, as above (even if it doesn't modify the C).

 b) Only committed changes from other transactions visible. No
    dependencies as above, but more conflicts (B needs to be aborted
    when it tries to increment C). Better parallelism in some cases.

Cheers,

  -- Nikodemus              Schemer: "Buddha is small, clean, and serious."
                   Lispnik: "Buddha is big, has hairy armpits, and laughs."