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-27 14:54:00

On Tue, Jan 26, 2010 at 1:36 PM,  <strasser_at_[hidden]> wrote:
> Zitat von Bob Walters <bob.s.walters_at_[hidden]>:
>
> I agree. it's probably 5 syncs for a transaction across 2 RMs.
> the TM  should also take into consideration if resources are persistent or
> not. Boost.STM for example is transactional memory only and does not
> maintain a log on disk, so when it is used together with 1 other persistent
> resource, the TM can perform a two-phase commit on the transient resource
> and a one-phase on the persistent resource.
>
> transient_resource->prepare();
> persistent_resource->commit(); //not prepared
> transient_resource_commit();
>
> the same is probably the case when your library is used in a non-file
> region?

There could be variations which are non-persistent, yes.

> do you see a reason why that would need support from the TM?
> when we've talked about the off-list I always assumed to implement that on
> the RM level.
> so when RM 1 offers service A and RM 2 offers service B, and they should
> share a log, a RM 3 is implemented that maintains the shared log and offers
> services A and B, forwarding service calls to RM 1 and 2.

Perfect. For some reason, I had assumed that different logs per RM
were required as part of this design.

> I don't use checkpoints, so I guess there would be no coordination needed,
> as long as your RM has access to the shared log?

Yes, I can deal with it in that way.  You mention that you have no
checkpoint, but I thought you would need occasional msync() of the
backing store, in order to eliminate the need for some of the logs,
and permit log archival.  Regardless, I think the coordination around
that could be the domain of the RM exclusively, and not part of the TM
/ RM interface.

> I think it's definitely worth looking at as an optimization, but imho not as
> an alternative to the distributed transaction approach, as you cannot make
> all resources share a log, e.g. a RDBMS resource.

True.  It would be great to ensure that when the different boost
transaction-capable libraries are used together, the log can be
shared.  This is the first that I had heard that your scope included
full distributed transaction support that could incorporate RDBMS
systems.