On Tue, Jan 26, 2010 at 1:36 PM, <strasser@uni-bremen.de> wrote:
Zitat von Bob Walters <bob.s.walters@gmail.com>:
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.