Re: [boost] [transact] transaction language macros (was: Re: [transact] code in sandbox)

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;

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/language.hpp?rev=59760

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