On Fri, Feb 12, 2010 at 7:54 AM, Vicente Botet Escriba <vicente.botet@wanadoo.fr> wrote:
With my macros or with yours, the user needs to be aware that the transaction block is included on a internal loop. Otherwise his code could not work. For example with your macro (that hides the transaction variable) the user is unable to exit successfully from the transaction block.
int f() { BOOST_TRANSACT_ATOMIC { ... return 1; // do not commits ... }BOOST_TRANSACT_COMMIT; }
will not behaves as the user expects. With the STM macros the user could do
int f() { BOOST_TRANSACT_ATOMIC(_) { ... _.commit(); return 1; // or BOOST_TRANSACT_RETURN(_, 1);
... } BOOST_TRANSACT_RETRY(_); }
Actually, looking back at the start of this whole thread, the original macros were 'do atomic{' and '}commit()' to specifically help show the do/while loop. And looking at the above, the RETRY macro at the end of f() doesn't do as effective a job conveying the presence of the loop. (IMHO.) You've made a good point here. The macros can hide too much from the end user. That is one of the things underlying my own dislike of macros. They save time writing code, but make it harder to read, and debug. The use of macros for these loops should be optional. For that matter, the loops are optional. In my library, a user can employ pessimistic locking conventions to ensure no chance of an isolation_exception, and in the process, would not need the retry loop.
when the user needs to have control over code-on-retry etc., using the macros is not less verbose and the user has to be aware of the details that this is implemented as a loop and a try/catch block. having more than one choice on which macro to use even adds complexity.
Maybe you are right, may be not. All these depend on whether we found a good macro name for each common use case. I hope we will find out these common use cases and appropriated names together.
I agree with Steffan on this point. Perhaps one way of approaching this, with a library like Boost.Transact is to have a clear, explicit model for dealing with a transaction, and provide some macros for the most common use case we can think of, and which we agree to be generic enough to apply to all 3 libraries. Additional macros, specific to capabilities that are only in one or two of the libraries could be provided with that library. For example, I do not currently have any capability to assign transaction priorities.