Zitat von Bob Walters <bob.s.walters@gmail.com>:
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.