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

Fri Apr 8 15:12:16 EDT 2005

Which version of the JavaDocs are you looking at? In 1.4 it says:

========================================
Modify the timeout value that is associated with transactions started  
by subsequent invocations of the begin method.

If an application has not called this method, the transaction  service 
uses some default value for the transaction timeout.
========================================

Whatever the case, even if it does just modify the current thread, that 
doesn't do us much good because the thread will be reused once the 
current whatever it is has finished. It could be another web request, 
it could be a service engine job, etc. Whatever it is, it won't be what 
we are running now. Heck, it could be another transaction in the same 
web request or service engine job.

Also, why are we talking about this? The changes I just committed 
should address this issue...

-David

On Apr 8, 2005, at 1:03 PM, Ryan Warnick wrote:

> The spec says that setTransactionTimeout sets the timeout for future
> transactions for the current thread and that is pretty much all it 
> says.
> Here is the exact language:
>
> setTransactionTimeout
> public abstract void setTransactionTimeout(int seconds)
> throws SystemException
> Modify the value of the timeout value that is associated with the
> transactions started by the current thread
> with the begin method.
> If an application has not called this method, the transaction service
> uses some default value for the transaction
> timeout.
> Parameters:
> Seconds
>
> So, in my opinion, JOTM's current implementation is wrong.  In any 
> case,
> this is really something that I should be talking to the JOTM team
> about.  If we can get them to fix this, then we won't have to sacrifice
> any concurrency on the Ofbiz side.
>
> 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:55 PM
> To: OFBiz Project Development Discussion
> Subject: Re: [OFBiz] Dev - RE: [OFBiz] SVN: r4785 -
> trunk/framework/jotm/lib
>
>
>
> 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
>
>
> __________ 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/d701a973/smime-0001.bin