Re: [boost] [transaction] New Boost.Transactionlibraryunderdiscussion

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 :)