|
Boost : |
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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk