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: vicente.botet (vicente.botet_at_[hidden])
Date: 2010-02-21 16:36:54

----- Original Message ----- 
From: <strasser_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Sunday, February 21, 2010 10:19 PM
Subject: Re: [boost] [transact] transaction language macros (was: Re: [transact] code in sandbox)

> 
> Zitat von "vicente.botet" <vicente.botet_at_[hidden]>:
>> I agree this doesn't means that the transaction can not be removed  
>> shortly thereafter, but neither the oposite, that is that the  
>> transaction will be destructed shortly thereafter. The transaction  
>> could be reused if the implementation is improved. I have already,  
>> as I showed in a previous mail, moved the transaction declaration  
>> out of the try, so the transaction out leaves the retry, and the  
>> internal loop.
> 
> as I've said before, although I don't see the need for restarting a  
> transaction,if you do, I'll implement it.
>
> it's not a big deal to implement, I only want to make sure to keep the  
> RM interface as simple as possible. but if it's necessary for stuff  
> like set_priority, not a problem.
> 
> interface:
> basic_transaction::restart();
> RM::restart_transaction(transaction &) if RM::services contains  
> transaction_restart_service_tag;
> TM::restart_transaction(transaction &), calls RM::restart_transaction  
> if available. reconstructs the transaction otherwise.
> ok?

I'm not forcing you to do that. I 'm just saying both approaches can be explored. I prefer you explore without restart, and I continue to explore with restart. We will see which approach is better when we will complete the round of features. 
 

>> As I said already
>>>> Maybe asserting  that there are no break/continue will be a good thing.
>> That is, I prefer option c)
> 
> ok, open issue then.
> but how does this relate to the fact that you see retry as an  
> equivalent to catch, as you've said below?
> you can "break" from catch-clauses.

Yes, we can. But the result of the break is that we don't retry, i.e. we abort the transaction. If you prefer you can throw an isolation_exception when the user uses break or continue instead of asserting it don't use it.
 
>>> what's wrong with explicitely stating the type of exception he wants
>>> to throw, instead of rethrowing an exception, even though there is no
>>> "catch" clause visible?
>>
>> If the user throws its own exception , s/he will need to catch it  
>> and do a specific action. If the exception is an  
>> isolation_exception, this exception will be catched by the outer  
>> transaction implicitly.
> 
> ok, then it's a matter of documentation, that "throw" not only  
> rethrows exceptions but also "retries".
> but please consider this case first:
> 
> try{
>   //...
> }catch(my_exc &){
>   transaction{
>     //...
>   }retry{
>     throw;
>   }
> }
> 
> is it expected behaviour that this rethrows isolation_exception, not my_exc?

yes, IMO the exception must be isolation_exception, or a specific exception the library documents and make the outer transaction to abort.

Regards,
Vicente