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

Subject: Re: [boost] [transaction] New Boost.Transaction library under discussion
From: Stefan Strasser (strasser_at_[hidden])
Date: 2010-01-18 16:02:38

Am Monday 18 January 2010 19:27:25 schrieb Oliver Kowalke:
> I would suggest a three phase model for transactions operating on shared
> resource:
>
> 1.) prepare phase: multiple readers/one writer have access to the resource
> 2.) modification phase: only one writer has access and can can modify
> the resource
> 3.) commit/rollback phase: write publishes its local modifications and
> releases the execlusive lock
>
> With this pattern you cold support queries and transactions in parrallel
> (at least for phase 1 and 3).

I would leave this up to the resources.
the resource only has to make sure that the state that was the basis for 
signalling a successful prepare-phase in a two-phase-commit is upheld until 
commit:
prepare: returns if the transaction can be committed.
commit: publish the local modifications. if prepare signalled a successful 
transaction, this has to succeed.

an exclusive lock to the entire resource could be used to upheld the state of 
the prepare phase until commit, but there are other ways.
my implementation e.g. never blocks another transaction from reading an 
object, even during commit, based on
http://en.wikipedia.org/wiki/Optimistic_concurrency_control and 
http://en.wikipedia.org/wiki/Multiversion_concurrency_control

Bob(STLdb) is more concerned about unnessary rollbacks because he expects a 
higher rate of concurrent access in indexes, so locks are even acquired in 
your "phase 1" and are upheld until commit.
both approaches might be right for their specific use case.