Subject: Re: [boost] [transaction] New Boost.Transactionlibraryunderdiscussion
From: Stefan Strasser (strasser_at_[hidden])
Date: 2010-01-21 16:43:22
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?
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
> 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.
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_;
}
}
> 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.
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?
>
> int main(){
> basic_transaction<txmgr> tx;
> ...
> tx.commit();
> }
>
> Can you found this code on your book? ;-)
no, not there :)