Zitat von "vicente.botet" <vicente.botet@wanadoo.fr>:
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.