Hi, ----- Original Message ----- From: "Stefan Strasser" <strasser@uni-bremen.de> To: <boost@lists.boost.org> Sent: Thursday, January 21, 2010 10:43 PM Subject: Re: [boost] [transaction] NewBoost.Transactionlibraryunderdiscussion
Am Thursday 21 January 2010 23:56:07 schrieb Vicente Botet Escriba:
I understand the intent of lazy constructing the local transactions. IMO this lazy construction can be done, but as soon as a resource has already a transaction, any global nested transaction should create a local transaction on it. All the resources have the same nested level of transaction except those that have none. This should solve the preceding issue, and let STM check for rollback only as soon as possible.
ok, that STM can check on each access makes it even easier: let's introduce a ResourceManager::check(transaction &) function, which is called by the TransactionManager every time a transaction is created or committed(or on every access?). then there is no need to create empty nested transactions, is there?
No, not really. So, you where right no need to create all the local transaction contexts. Do you need to create all the nested transactions lazyly up to the bottom? In the implementation you talked about an optimization.
this could even be exposed to the user as basic_transaction<>::check(), which checks each resource, so he can do something like this:
transaction tx;
//modify res
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.
if (instance_==0) { scoped_lock<mutex> lk(mtx_); if (instance_==0) instance_ = new txmgr(...); } // here instance_!= 0
I used something like that in basic_transaction_manager::resource_transaction before, but I believe this is invalid code.
This is not correct code but it is portable to a lot of compilers. The implementation can of course be made more robust using atomic to access the instance_ field on comilers that don't ensure atomicity on readig/writing a pointer. Anyway you see the idea, it is the Final class that constructs the instance. Not the mixin. And the singleton protocol can be ensured by another mixin, or by the vasic_transaction_manager itself.
what stops the compiler from inlining the txmgr constructor and decomposing it into code like this?
if(instance_==0){ scoped_lock<mutex> lk(mtx_); if(instance_==0){ instance_=operator new(sizeof(txmgr)); //construct the txmgr in instance_; } }
I don't see what is the issue.
return *instance_; } static char *db_filename; ... }; char * txmgr::db_filename="file.db";
I put that in main() because configuration options might be determined at runtime. but ok, that might be quite rare.
This is way I said that this should be associated to a resource. There are some resourcess that could need some open/connect close/disconnect specific phases. This resources can not participate on a transaction out of this [open,close] interval.
From my point of view an application should be able to work with transactional data, connect/disconnect to a database as many times as it is needed, without for this needing to stop the transaction manager, but maybe I'm wrong.
I'd still prefer that it's the user's obligation to construct a transaction manager, but maybe that's also just a difference in style. what exactly is your issue with that? that the user could make a programming error by omitting the construction?
As I said before if the user can bind itself, the last bind overrides the preceding. This introduce interaction problems between different parts of the application. Which one should make the bind? This does not means that a resource manager can not have its own bind (connect/disconnect) protocol. Vicente