Boost logo

Boost :

Subject: Re: [boost] [transact] transaction language macros (was: Re: [transact] code in sandbox)
From: strasser_at_[hidden]
Date: 2010-02-19 16:06:06

Zitat von "vicente.botet" <vicente.botet_at_[hidden]>:

> 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;

can't you catch the exceptionb outside of the scope?

     throw my_exc();
catch(my_exc &) {

> * 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

//user code

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"

> As any macro in Boost.Transact must be prefixed with BOOST_TRANSACT, maybe

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


is defined to


when "BASIC_TRANSACT_" is kind of the namespace of the macro.


> We could add a 3rd level of try-catch around the user code, so the
> user can do
> //...

I still don't get it ;)

Boost list run by bdawes at, gregod at, cpdaniel at, john at