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.
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)