Hi Adrian,
Ah, the minimalist approach.
So, logging etc is the client's responsibility.
OK by me.
Cheers
Paul Foxworthy
Adrian Crum-3 wrote:
>
> GenericEntityException is caught, the transaction is rolled back, and the
> exception is re-thrown.
>
> -Adrian
>
>
> On 4/28/2011 7:24 PM, Paul Foxworthy wrote:
>> Hi Adrian,
>>
>> The key point of difference is catches. The rest, as you say, is
>> boilerplate
>> stuff that can be encapsulated.
>>
>> Client code could do whatever it wanted in catches, and if I'm reading
>> you
>> right you're proposing encapsulating a standardized catch. That might not
>> be
>> what the client wants under all circumstances.
>>
>> Possible solutions are:
>>
>> - No catch within runTransactionTask
>> - Standard catch within runTransactionTask, and rethrow the exception. I
>> assume the catch would log the error.
>> - Add an overloaded variant of runTransactionTask with a boolean
>> parameter
>> to say whether or not the standard catch behaviour is wanted
>> - I did contemplate a system-wide property that can be configured to turn
>> the standard catch on or off by default, but I think that would be too
>> drastic, and client code should have the option case-by-case. I might be
>> wrong.
>> - Don't use runTransactionTask if the standard catch is not wanted
>>
>> These are not all mutually exclusive!
>>
>> Do you have standard catch behaviour in mind?
>>
>>
>> Adrian Crum-3 wrote:
>>> Setting up transactions properly can be complicated. I've seen cases
>>> where it was done wrong. Even when it's done right, it adds a lot of
>>> client code that gets repeated every time a transaction is used. I have
>>> an idea to make transaction handling easier and more reliable:
>>>
>>> 1. Create an interface:
>>>
>>> public interface TransactionTask {
>>> void run() throws GenericEntityException;
>>> }
>>>
>>> 2. Add a method to TransactionUtil.java:
>>>
>>> public static void runTransactionTask(TransactionTask task, boolean
>>> suspendCurrent) throws GenericEntityException,
>>> GenericTransactionException
>>> {
>>> ...
>>> }
>>>
>>> The TransactionUtil.runTransactionTask method will contain all of the
>>> correct begin, suspend, commit, resume, rollback, try, catch, finally
>>> logic. All the client code needs to do is put the transaction-protected
>>> code in a TransactionTask instance run() method and call the
>>> TransactionUtil.runTransactionTask method. Bottom line - less code,
>>> better results.
>>>
>>> Example:
>>>
>>> TransactionTask task = new TransactionTask() {
>>> public void run() throws GenericEntityException {
>>> GenericValue target = delegator...;
>>> target.set("someField", "someValue");
>>> target.store();
>>> }
>>> };
>>> TransactionUtil.runTransactionTask(task, true);
>>>
>>>
>>> What do you think?
>>>
>>> -Adrian
>>>
>>
>> --
>> View this message in context:
>> http://ofbiz.135035.n4.nabble.com/Discussion-New-TransactionUtil-java-Methods-tp3473477p3482728.html
>> Sent from the OFBiz - Dev mailing list archive at Nabble.com.
>
--
View this message in context:
http://ofbiz.135035.n4.nabble.com/Discussion-New-TransactionUtil-java-Methods-tp3473477p3491844.html
Sent from the OFBiz - Dev mailing list archive at Nabble.com.
