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

Subject: Re: [boost] [transaction] New Boost.Transaction library under discussion
From: Bob Walters (bob.s.walters_at_[hidden])
Date: 2010-01-18 23:39:30

On Mon, Jan 18, 2010 at 4:02 PM, Stefan Strasser <strasser_at_[hidden]> wrote:

> 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

How do you control atomicity with this design?  i.e. If a transaction
modifies A and B and you are using a lock-free approach to update the
cached versions of these objects from their shadow copies, how do
you ensure that any other threads which might be reading A and B (or B and A)
see the two entries consistently?  Is this isolation enforced, or can other
threads see a mixture of A and B from before/after the commit point?