Subject: Re: [boost] [transact] transaction language macros (was: Re: [transact] code in sandbox)
Date: 2010-02-21 16:19:47
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.
RM::restart_transaction(transaction &) if RM::services contains
TM::restart_transaction(transaction &), calls RM::restart_transaction
if available. reconstructs the transaction otherwise.
> 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.
>> 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:
is it expected behaviour that this rethrows isolation_exception, not my_exc?
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk