$include_dir="/home/hyper-archives/boost/include"; include("$include_dir/msg-header.inc") ?>
Subject: Re: [boost] [transaction] New Boost.Transaction library under discussion
From: strasser_at_[hidden]
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
> shared.
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.