Boost logo

Boost :

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.


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