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
>> algorithm is pushed into Callable.call, you can use the chain pattern to
>> automatically do transaction processing, caching, or eca stuff.
> 
> I wouldn't say the transaction processing is "wrong". Sounds like it's
> different from what you expect.
> 
> 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
> 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.

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.

(I'm trying to configure some hardware for a halloween party right now,
so can't respond to your other stuff)

Reply via email to