Zitat von "vicente.botet" <vicente.botet@wanadoo.fr>:
int priority=0; begin_transaction{ //... }retry{ stm::set_priority(priority++); }end_retry;
inside the retry-clause the transaction object is destructed and no new one is constructed yet. STM could provide an API for setting the priority of the next transaction, using thread-specific storage to support this. I think the only way to support this on the macro level is using a boost::optional to hold the transaction, which probably introduces runtime overhead. (and I think another problem like the one below regarding "___control=0")
* committing the transaction and rethrowing a specific exception:
begin_transaction{ try{ //... throw my_exc(); //... }catch(my_exc &){ commit(); throw; } }end_transaction;
it seems to me that this already is (unintentionally) supported. (using active_transaction().commit()). the scope is exited with an exception, so it does not commit again. commit_on_destruction is nullified. only if the user commits manually and does not throw an exception there is a problem, but I think we can leave this case undefined. just like calling transaction::commit() two times in a row.
* rollback the transaction and ignore a specific exception:
begin_transaction{ try{ //... throw my_exc(); //... }catch(my_exc &){ rollback(); or set_rollback_only(); } }end_transaction;
hmm...why? can't you catch the exceptionb outside of the scope? try{ begin_transaction{ throw my_exc(); }end_transaction; catch(my_exc &) { //ignore }
* Should the following compile?
begin_transaction statement1; statement1; end_transaction;
it currently does. if we want to adhere to the syntax of a language extension: transaction /statement/ we could enforce this by wrapping the user code in do //user code while(false); which supports a single statement and compound statements, but not multiple statements. I'm in favor of this. I used something similar to enforce the semicolon after "end_transaction".
* Just a remark: the following case doesn't do what the user could expect as the user is unable to set the variable __control to 0. It
this only affects the case the user "break"s from the retry clause. see my other email.
begin_transaction{ try{ //... }catch(boost::transact::isolation_exception & ex){ // do something before retry } }end_transaction;
if we move the __control=0; from the catch(isolation_exception &) clause up to the catch(...) one, the above use case seems OK. neither in the case that the whole transaction scope is exited by an exception , nor in the case that the retry-loop is continued the value of __control matters. it's only set to 0 for the "break out of retry" case.
As any macro in Boost.Transact must be prefixed with BOOST_TRANSACT, maybe BOOST_TRANSACT_TRANSACTION/BOOST_TRANSACT_END could be more appropiated than BOOST_TRANSACT_BEGIN_TRANSACTION/BOOST_TRANSACT_END_TRANSACTION
I thought about that, but since there are now multiple macros I also wanted to #define the lower case macros without prefix, if the user chooses to include them. I'd find it slightly confusing that end_transaction is defined to BASIC_TRANSACT_END when "BASIC_TRANSACT_" is kind of the namespace of the macro. see https://svn.boost.org/trac/boost/browser/sandbox/transaction/boost/transact/...
We could add a 3rd level of try-catch around the user code, so the user can do
BOOST_TRANSACT_TRANSACTION { //... } BOOST_TRANSACT_ON_EXCEPTION(Ex1) {
I still don't get it ;)