Boost logo

Boost :

Subject: Re: [boost] [transaction] NewBoost.Transactionlibraryunderdiscussion
From: Stefan Strasser (strasser_at_[hidden])
Date: 2010-01-22 13:55:07


> +1 for removing TransactionManager::bind() and ::has_active(), and make
> its constructor throw if there already is a TransactionManager
>
> +1 to support connecting/disconnecting resources to support opening one
> database file first and then another

I have now implemented that, with one difference:
why even construct a basic_transaction_manager when it is a singleton and all
of its state is mutable(connecting and disconnecting resources)?
basic_transaction_manager now has only static members, e.g.
TxMgr::active_transaction():

https://svn.boost.org/svn/boost/sandbox/transaction/dev/basic_transaction_manager.hpp

changeset:
https://svn.boost.org/trac/boost/changeset/59230

Am Friday 22 January 2010 16:29:33 schrieb Vicente Botet Escriba:
> strasser wrote:
> >>> tx.check();
> >>>
> >>> //do something unrelated, non-transactional, that takes a while
> >>>
> >>> //continue modifying res
> >>
> >> check doesn't means to much, we will need something more specific.
> >> But we will see.
> >
> > what do you mean? the function name or anything beyond that?
>
> The name. Something more explicit as abort_if_rollback_only().

I'd use check_transaction or something like that. calling it
abort_if_rollback_only() sounds like calling commit_transaction()
publish_if_no_conflict().

> > that the pointer might not be an atomic type on some exotic platform
> > is not the issue, I believe this code is also invalid on x86.
> > when there is a thread switch at (**) another thread goes ahead with
> > an unconstructed transaction manager!
>
> Oh, you where loking for that error. What about
>
> txmgr* tmp=operator new(sizeof(txmgr));
> //(**)
> //construct the txmgr in tmp;
> instance_=tmp;

how do you control that? Boost.Atomic?
that would probably be close to using a mutex (at least a memory fence), but
the issue is now irrelevant anyway.


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk