Re: [boost] [transact] code in sandbox

Subject: Re: [boost] [transact] code in sandbox
From: Bob Walters (bob.s.walters_at_[hidden])
Date: 2010-02-17 01:25:54

On Fri, Feb 12, 2010 at 7:54 AM, Vicente Botet Escriba
<vicente.botet_at_[hidden]> 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.