Re: Simplifying GenericDelegator

[David E Jones]

On Oct 25, 2007, at 8:48 PM, Adam Heath wrote:

David E Jones wrote:

Transaction processing is wrong. There are error conditions that will not cause a rollback to occur; namely, Runtime or Errors. The proper way to do this, is to set a flag to true right before the inner block is

done processing, then checking that flag in the finally block, and
calling rollback/commit appropriate.  Ie:

public static <V> V runTransaction(Callable<V> proc) {
    boolean success = false;
    boolean beganTx = false;
    try {
        beganTx = TransactionUtil.begin();
        V result = proc.call();
        success = true;
        return result;
    } finally {
        if (success) {
            TransactionUtil.commit(beganTx);
        } else {
            TransactionUtil.rollback(beganTx);
        }
    }
}

The above is an example only.  The pattern is so common, that I've
created a local class for our application, to make this easier.
Ideally, I should send that to ofbiz.

Another nice benefit of the above, is that since the meat of the

automatically do transaction processing, caching, or eca stuff.

algorithm is pushed into Callable.call, you can use the chain pattern to

different from what you expect.


missed. This is a fairly material change in error handling and might
cause dependent code to need changes. Whatever the case, I'd rather
focus on solving problems, especially since most of this code and the
techniques in it are pretty well vetted and tested.

I wouldn't say the transaction processing is "wrong". Sounds like it's This is how it has been, and it isn't my intention right now to change the error handling semantics of these methods. And, BTW, YOU should not either unless you discuss it on the list to maybe catch some things you

Consider a NullPointerException being thrown while inside a
try/catch/finally block.  Since the RuntimeException isn't caught, and
the rollback is only called when the listed exceptions are thrown, and
the commit is never called, then the transaction is never closed, and
will leak.

Actually, the commit is in the finally, so the transaction should never leak. The question, I suppose, is do we consider an NPE something to cause a rollback? Historically the answer for the Entity Engine was no.

(I'm trying to configure some hardware for a halloween party right now,

so can't respond to your other stuff)

-David

Sounds like fun. From my reply you can probably tell I'm thinking of being a fisticuffs redneck. ;)

smime.p7s
Description: S/MIME cryptographic signature