Subject: Re: [boost] [transaction] New Boost.Transaction library under discussion
Date: 2010-01-27 17:15:28
Zitat von Bob Walters <bob.s.walters_at_[hidden]>:
> 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,
is that what you mean by checkpoints? I assumed you meant exporting
the entire state from time to time, so checkpoint + log = current state.
anyway, this is currently managed by the storage log itself, though
this is not set in stone:
in addition to a commit message there is a "success" message written
to the log, i.e. "this transaction has reached disk". the log only
removes old logs when there's been a success message for each
transaction in it.
so the RM can delay the success messages (and therefore the sync) as
long as it wants, it is only prompted by storage_log::overflow()==true
to post its success messages.
so I guess it won't be too much coordination if we end up using this log.
> 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
do you also include the TM log in this?
e.g. when there is a RDBMS, and a logging boost library, the boost RM
maintains a log and the TM does for the distributed transactions with
the RDBMS RM.
so the RM and the TM could also use a shared log, but I tend to think
this is not worth the effort, as this would span the interface between
RM and TM.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk