[rucksack-devel] Re: Rucksack, ECLM

[Arthur Lemmens]

[Luke: I keep you on CC now, but if you want to keep following
this you'd better subscribe to rucksack-devel at common-lisp.net,
which was created yesterday.]

Nikodemus wrote:

> Getting back to this after pulling my head out of my rectum...

I'm not sure what this refers to?

> Scenario:
>
>  C (counter) has value 0.
>
>  A (transaction) enters.
>  A increments C -> 1.
>  B (transaction) enters.
>  B sees the pristine C (as A hasn't committed yet), and increments it C -> 1.
>
> at this point only one of the two can commit, as their views aren't
> consistent anymore. After both have succesfully committed C should b
> 2.
>
> Since rollbacks are expensive the abort should happen as soon as
> possible, and it needs to be B so that younger transactions cannot
> starve older ones. Ergo, B should be aborted when it tries to
> increment C.

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.

'Multiple versioning' is used both in memory and on disk, and the
rule for fetching values is the same. (Although the implementation is
quite different: in memory, you find a dirty object from its ID by
finding the relevant transaction first and then looking the object up
in the transaction's dirty-objects hash-table.  On disk you find the
most recently committed object version and then follow pointers to
previously committed object versions if necessary.)

The rule for fetching values ('objects' is probably a better word
here) is: use the object version that has been modified by the
youngest transaction that is older than (or the same as) the current
transaction.

So let's do your scenario again:

>  C (counter) has value 0.
>
>  A (transaction) enters.
>  A increments C -> 1.
>  B (transaction) enters.
>  B sees the pristine C (as A hasn't committed yet)

No, this part is wrong.  According to the rule above, B will see
the version of C modified by A.

> and increments it C -> 1.

No, it will increment it to 2.  But A should still see C=1; if A
tries to change C again (after B has changed it), B will be
aborted (like we discussed earlier).

Now that we're talking about this, I realize that there's a bug in
my implementation of all this: at the moment I don't actually make
in-memory copies of modified objects; I only do that for committed
(on disk) versions.  So I should revisit CACHE-TOUCH-OBJECT (and
the functions that call CACHE-TOUCH-OBJECT) to make sure that this
happens at the right moment.

That's the scheme I had in mind.  Does that sound reasonable to you?

Arthur

(I'll reply to your other points in another email.  This one is long
enough as it is.)