Boost logo

Boost :

Subject: Re: [boost] [transact] code in sandbox
From: vicente.botet (vicente.botet_at_[hidden])
Date: 2010-02-17 16:08:09


----- Original Message -----
From: <strasser_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Wednesday, February 17, 2010 7:13 PM
Subject: Re: [boost] [transact] code in sandbox

>
> Zitat von Vicente Botet Escriba <vicente.botet_at_[hidden]>:
>>
>> abort/rollback will abort the current transaction on the point of call,
>> force_to_abort/set_rollback_only don' make the transaction to abort/rollback
>> immediately, but tell to the the transaction that it must be
>> aborted/rolledback next time we try to commit it.
>
> some more details:
>
> 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.
A no_active_transaction would be even better. I will change this point.

The use of macros should ensure that there is no operation out of protocol, so the cases 3/4/5/6 should never occur.

Vicente


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