2 corrections:
begin_transaction{ try{ //... }catch(boost::transact::isolation_exception & ex){ // do something before retry } }end_transaction;
if we move the __control=0; from the catch(isolation_exception &) clause up to the catch(...) one, the above use case seems OK. neither in the case that the whole transaction scope is exited by an exception , nor in the case that the retry-loop is continued the value of __control matters. it's only set to 0 for the "break out of retry" case.
what I wrote here is nonsense. if the user "break"s in a self-defined catch(isolation_exception &) clause like you've shown above, the user's loop is affected. the value of __control is set correctly. if the user rethrows, the value doesn't matter.
As any macro in Boost.Transact must be prefixed with BOOST_TRANSACT, maybe BOOST_TRANSACT_TRANSACTION/BOOST_TRANSACT_END could be more appropiated than BOOST_TRANSACT_BEGIN_TRANSACTION/BOOST_TRANSACT_END_TRANSACTION
I thought about that, but since there are now multiple macros I also wanted to #define the lower case macros without prefix, if the user chooses to include them. I'd find it slightly confusing that
end_transaction
is defined to
BASIC_TRANSACT_END
when "BASIC_TRANSACT_" is kind of the namespace of the macro.
...unless we wanted to make the keywords "begin", "retry" and "end". I'm in favor if simple keywords, C++'s "try" and "catch" aren't very specific either. but unfortunately "begin" and "end" are used in STL containers.