Re: [boost] [transact] code in sandbox

Subject: Re: [boost] [transact] code in sandbox
From: strasser_at_[hidden]
Date: 2010-02-17 16:47:18

Zitat von "vicente.botet" <vicente.botet_at_[hidden]>:
>>
>> 1)
>> transaction tx;
>> tx.rollback_only();
>> tx.commit(); //does what? throw? which exception?
>>
>> 2)
>> transaction tx;
>> tx.rollback_only();
>> pers_obj->value=1; //does what?
>> //a) throw? which exception?
>> //b) go ahead, only throw on commit.
>>
>> 3)
>> transaction tx;
>> tx.rollback();
>> tx.commit(); //throw? which exception?
>>
>> 4)
>> transaction tx;
>> tx.rollback();
>> pers_obj->value=1; //throw? which exception?
>>
>>
>> please explain why for each case.
>> current behaviour is the following, but subject to change:
>> 1/2: non-existent
>> 3: undefined behaviour(my RM throws no_active_transaction)
>> 4: throw no_active_transaction()
>
> I will add also
> 5)
> transaction tx;
> tx.commit();
> tx.rollback();
>
> 6)
> transaction tx;
> tx.commit();
> pers_obj->value=1;
>
> Currently TBoost.STM throw aborted_transaction_exception in 1/2.
> 3/4/5/6 ignore the call as the transaction is not in the active state.

the reason for this list was my suspicion that rollback_only() isn't  
really necessary, and this confirms it.

since 3-6 can be undefined, we can use rollback() instead of rollback_only():

transaction tx;
tx.rollback();
tx.commit(); //throws no_active_transaction

transaction tx;
tx.rollback();
pers_obj->value=1; //throws no_active_transaction

I would have understood if you wanted to support the following:

A::~A(){
   try{
     pers_obj->value=1;
   }catch(isolation_exception &e){
     transaction_manager::active_transaction().rollback_only();
   }catch(...){
     transaction_manager::active_transaction().rollback();
   }
}

a transaction marked rollback would then throw isolation_exception on  
following accesses, and an actually rolled back transaction would  
throw no_active_transaction.
was that your intention?

if so, I still think we don't need rollback_only() if we define that a  
transaction that once emitted a isolation_exception has to emit it  
over and over again on following accesses and commit()s.
a destructors can then simply ignore isolation_exceptions, as they  
will be rethrown when the caller tries to commit the transaction.