[OFBiz] Dev - RE: [OFBiz] SVN: r4785 - trunk/framework/jotm/lib

[David E. Jones]

I don't think it's that simple. There is a specific that JOTM 
implements and it needs to work according to that implementation.

In OFBiz we can't rely on fudging being done on the other side of a 
standard interface, because it may be used with other transaction 
managers (ie in other app servers and such).

Unless, of course, that is how it should be according to the spec, but 
I'm pretty sure that is not the case.

-David


On Apr 8, 2005, at 12:41 PM, Ryan Warnick wrote:

> I looked at the UserTransaction interface and I agree that there are
> some limitations on what can be done.  Couldn't the JOTM team use a
> thread local variable to handle this?  This wouldn't limit concurrency
> and would avoid a significant redesign.
>
> setTransactionTimeout would set or create a thread local variable if 
> the
> value is > 0 and remove the thread local variable if the value is <= 0.
> Also, in begin(), the code could be modified to check for a thread 
> local
> variable and use it if present.  If one wasn't present, it would use 
> the
> default timeout.
>
> Ryan
>
> -----Original Message-----
> From: dev-bounces at lists.ofbiz.org [mailto:dev-bounces at lists.ofbiz.org]
> On Behalf Of David E. Jones
> Sent: Friday, April 08, 2005 12:13 PM
> To: OFBiz Project Development Discussion
> Subject: Re: [OFBiz] Dev - RE: [OFBiz] SVN: r4785 -
> trunk/framework/jotm/lib
>
>
>
> Ryan,
>
> Which object in particular are you referring to here that has the
> transactionTimeout variable? Are you referring to the UserTransaction
> object?
>
> There isn't much we can do about that, it's part of the JTA spec. There
> probably isn't much they can do inside the implementation of that
> interface either... Another great  artifact of OO design gone awry...
>
> One possible solution is in our own TransactionUtil.begin method to
> synchronize the whole method. We could synchronize just the are around
> those 2 calls (which are right next to eachother), but as I understand
> it that is not entirely safe, best if the whole method is synchronized.
>
> Looking at this code, there is another problem.... It sets the
> transaction timeout, but never sets it back to the default... I added a
> fix for that too.
>
> That is in SVN now.
>
> -David
>
>
> On Apr 8, 2005, at 11:19 AM, Ryan Warnick wrote:
>
>> I just had a look at the fix in JOTM and it still looks like there is
>> an
>> issue.  Even though some of the problems were resolved, there is still
>
>> a
>> race condition.  Here is my thinking:
>>
>> The core issue is that there is only ONE Current object and it has
>> only ONE member variable called transactionTimeout.  Ofbiz uses the
>> begin() method which sets the transaction timeout value for the new
>> transaction to the value of transactionTimeout.  So, if one thread
>> calls setTransactionTimeout and sets the timeout to 60 seconds and
>> before that same thread can call begin another thread calls
>> setTransactionTimeout and sets it 30 seconds, then the original
>> thread's transaction timeout will be 30 seconds.  The
>> transactionTimeout member variable is being shared by all threads and
>> it seems like only way to prevent the race condition is to make calls
>> to setTransactionTimeout and begin atomic. Of course, there are some
>> better ways to address this issue, such as having a begin() method
>> that accepts the timeout as an input and just uses it locally for the
>> transaction.
>>
>> Ryan
>>
>> -----Original Message-----
>> From: svn-bounces at lists.ofbiz.org [mailto:svn-bounces at lists.ofbiz.org]
>> On Behalf Of jaz at svn.ofbiz.org
>> Sent: Thursday, April 07, 2005 3:07 PM
>> To: svn at lists.ofbiz.org
>> Subject: [OFBiz] SVN: r4785 - trunk/framework/jotm/lib
>>
>>
>> Author: jaz
>> Date: 2005-04-07 16:06:19 -0500 (Thu, 07 Apr 2005)
>> New Revision: 4785
>>
>> Modified:
>>    trunk/framework/jotm/lib/carol.jar
>>    trunk/framework/jotm/lib/jotm.jar
>>    trunk/framework/jotm/lib/jotm_iiop_stubs.jar
>>    trunk/framework/jotm/lib/jotm_jrmp_stubs.jar
>> Log:
>> updated to JOTM 'HEAD' (pre 2.0.9) which fixed setTransactionTimeout()
>
>> bug
>>
>>
>> Modified: trunk/framework/jotm/lib/carol.jar
>> ===================================================================
>> (Binary files differ)
>>
>> Modified: trunk/framework/jotm/lib/jotm.jar
>> ===================================================================
>> (Binary files differ)
>>
>> Modified: trunk/framework/jotm/lib/jotm_iiop_stubs.jar
>> ===================================================================
>> (Binary files differ)
>>
>> Modified: trunk/framework/jotm/lib/jotm_jrmp_stubs.jar
>> ===================================================================
>> (Binary files differ)
>>
>>
>> _______________________________________________
>> Svn mailing list
>> Svn at lists.ofbiz.org http://lists.ofbiz.org/mailman/listinfo/svn
>>
>>
>>
>> __________ NOD32 1.1049 (20050406) Information __________
>>
>> This message was checked by NOD32 antivirus system.
>> http://www.nod32.com
>>
>>
>>
>> _______________________________________________
>> Dev mailing list
>> Dev at lists.ofbiz.org
>> http://lists.ofbiz.org/mailman/listinfo/dev
>
>
> __________ NOD32 1.1049 (20050406) Information __________
>
> This message was checked by NOD32 antivirus system.
> http://www.nod32.com
>
>
>
> _______________________________________________
> Dev mailing list
> Dev at lists.ofbiz.org
> http://lists.ofbiz.org/mailman/listinfo/dev
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2363 bytes
Desc: not available
Url : http://lists.ofbiz.org/pipermail/dev/attachments/20050408/6d91d186/smime.bin