----- Original Message ----- From: <strasser@uni-bremen.de> To: <boost@lists.boost.org> 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@wanadoo.fr>:
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