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-19 07:23:35

Am Tuesday 19 January 2010 05:39:30 schrieb Bob Walters:
> 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?

that's part of the optimistic approach, a transaction is allowed to see an 
inconsistent (inter-object) state, but it is guaranteed to fail with an 
isolation_exception, at commit at the latest, if it did.
(there were also pessimistic transactions once, but they fell victim to some 
refactoring...)

> I'm not against throwing away portions of my code base to better unify.

I'm neither.
could you point me to your free list/allocation code? my library spends a lot 
of time allocating and deallocating disk space, I guess there could be 
improvements.
my logger is already pretty generic (because I planned to use it for the 
storage engine log and for the log of the transaction manager for distributed 
transaction). here's some example code on how to use it:

typedef mpl::vector<
  map_inserted, //must be POD
  map_entry_removed,
  ...,
  > entries;

olog<entries> myolog(...);

myolog << map_inserted(1,2,3);
myolog << map_entry_removed(4,5);

---
struct listener{
  void operator()(map_inserted){
  }
  void operator()(map_entry_removed){
  }
};
ilog<entries> myilog(...);
myilog >> listener();
hidden behind olog is all the log rolling and the syncing interval stuff we've 
discussed to ensure sequential writing performance.