Re: [boost] [transaction] New Boost.Transaction library under discussion

Subject: Re: [boost] [transaction] New Boost.Transaction library under discussion
From: strasser_at_[hidden]
Date: 2010-01-19 14:42:57

Zitat von Bob Walters <bob.s.walters_at_[hidden]>:
>
> t1: modifies A and B, commits.
> t2: reads A and sees the newly committed value from t1
> t2: reads B it *must* see the committed value of B from t1, or from
> some later commit, and not a value from before t1.
>
> IIUC there is a race condtion which could allow t2 to see the older
> value of B if t1 and t2 overlayed in just the right way. (?)  Although
> your optimistic locking will protect t2 from an update to an old
> version of B, it won't prevent t2 from using B in a read-only manner
> (IIUC?), thinking that the value is current and correct.   To me
> that's a problem.

this is indeed something an optimistic implementation has to take care  
of, but it is taken care of:

case 1:
t1: reads A
t2: modifies A, commits
t1: reads A again //throws

case 2:
t1: reads A
t2: modifies A, commits
t1: uses the value read above from A to modify B.
t1: commits //throws

there is some problems with optimistic transactions with algorithms  
that can´t handle this kind of inter-object inconsistency, but it can  
never lead to an
inconsistent database state.
I think this is more an academic problem than it is practical, and a  
lot of databases don´t allow these kinds of algorithms I think. for  
example:

int *array=new int[123];
loc<pers_type> a=...;
loc<pers_type> b=...;

array[a->value - b->value]=1;

this depends on a consistent inter-object state at any time.
even though the transction would fail on commit, your application has  
already crashed before the commit is reached.
a pessimistic transaction would have to be used here.
I haven´t (re-)implemented those as I figured it is a too obscure  
feature that anyone would ever use it.

> I'm working on this currently with the checkpoint algorithm, and it
> isn't checked in yet.
> But I'm using a multimap keyed by chunk size to implement best fit.

I currently also use a intrusive multiset by size and an intrusive set  
by offset, to be able to match by size and merge blocks on deallocation.
since even a modified object requires an allocation it can be quite  
costly managing the maps.