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-21 20:49:28

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

>> I'm pretty sure you're trying to stop the user from shooting himself
>> in the foot here.
>> instead of "break", the user could also "return" from a retry clause.
>> or throw an exception and absorbing it outside of the transactino
>> scope, with similar results.
>> I think "break" should break, not assert and not throw, just because
>> we think this is what the user should have done.
>
> The difference is that the user would not write a retry block on a  
> sequential program, retry is specific of transactions. As we are not  
> used to work with retry, maybe the best is to allow it to choose if  
> s/he prefer to let break/continue to be used, asserted or throw an  
> isolation_exception. The default could be to exit the user loop.  
> What do you think?

that's even worse ;)
my point is that rearely will anyone ever intentionally use this, so  
it should behave as you would expect without learning anything, or be  
able to be documented easily.

1. "loop control statements can be used in transaction/retry blocks.  
they affect loops around it."

2. "when loop control statements are used in transaction blocks, they  
affect... Loop control statements in retry blocks result in undefined  
behaviour."
(assertion in debug mode)

3. "when loop...in transaction blocks... the behaviour of control  
statements in retry blocks can be configured. here is how you  
configure it: ......."

>           try {throw;}catch (boost::transact::isolation_exception &)

this has runtime overhead. throwing is an external function call on  
the compilers I use, even in this trivial case.
I don't know if there is another way to enforce compound statements  
(and I don't know why "catch" requires one).

>
>
> I have a question related to unwind. Instead of
>
>    }catch(boost::transact::isolation_exception &___i){ \
>     ___i.unwind<TXMGR>(); \
>
> I have the equivalent of
>    } catch (boost::transact::isolation_exception &) { \
>      if (__tx.is_nested()) throw; \

not equivalent. "is_nested() throw;" would always unwind the  
traqnsaction stack completely, up to the root transaction.
but sometimes a conflict is detected that is e.g. caused by 2  
contending nested transactions, so only one nested transactions needs  
to be repeated.

how unwind() works, pseudocode:

transaction *txonstack= <parent transaction of active_transaction(), or 0>;
throw isolation_exception(txonstack);

...
...

catch(isolation_exception &i){
   i.unwind();
   assert(&active_transaction() == txonstack);
}

so the code throwing the isolation_exception(typically the RM) can  
decide which transaction will be active when unwind() returns.