Zitat von Bob Walters <bob.s.walters@gmail.com>:
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.