Subject: Re: [boost] [transact] transaction language macros (was: Re: [transact] code in sandbox)
From: strasser_at_[hidden]
Date: 2010-03-05 15:44:17
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.
I think there is another problem with the restart-approach, unless the
following use case should be invalid:
transaction{
...
}retry{
transaction{
...
}
throw 1;
}
with the current approach, inside the retry-clause there is a current
transaction which is not active. the second transaction-scope tries to
create a nested transaction of the inactive transaction - and throws
no_active_transaction.
is it a valid use case to run a transaction inside a retry-clause?
if not, why not?
(btw, I'm going to change TM::active_transaction() to
TM::current_transaction() and add a bool basic_transaction::active(),
since the current transaction is not necessarily active at all times,
like in a retry clause)