You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@openjpa.apache.org by "roger.keays" <ro...@ninthavenue.com.au> on 2007/01/05 01:09:02 UTC

race condition in a transaction?

Hi,

I'm just wondering if the following code could be subject to a race
condition when accessed by many threads

em.getTransaction().begin();
bean.setCount(bean.getCount() + 1);
em.getTransaction().commit();

My understanding is that it would be possible here for two threads to set
the same value for the new count (given that each thread has a different
em). Is that correct?

Do I have to use an UPDATE query to make this function as expected?

Thanks,

Roger
-- 
View this message in context: http://www.nabble.com/race-condition-in-a-transaction--tf2922964.html#a8170503
Sent from the open-jpa-dev mailing list archive at Nabble.com.


Re: race condition in a transaction?

Posted by Craig L Russell <Cr...@Sun.COM>.
You need to watch out for pessimistic transactions using read- 
committed isolation level, which indeed has a race condition.

It's also not any different to get JPQL UPDATE to work as you want it  
to, with read-committed isolation. All the JPQL does for you is to do  
the same work in QL that you are now doing in Java.

Craig

On Jan 4, 2007, at 10:43 PM, Patrick Linskey wrote:

> Assuming that you're using some sort of locking strategy  
> (pessimistic or
> optimistic), then only one tx will successfully commit.
>
> You should only really use the UPDATE and DELETE JPQL statements for
> bulk operations, not for day-to-day persistence work.
>
> -Patrick
>
> -- 
> Patrick Linskey
> BEA Systems, Inc.
>
> ______________________________________________________________________ 
> _
> Notice:  This email message, together with any attachments, may  
> contain
> information  of  BEA Systems,  Inc.,  its subsidiaries  and   
> affiliated
> entities,  that may be confidential,  proprietary,  copyrighted   
> and/or
> legally privileged, and is intended solely for the use of the  
> individual
> or entity named in this message. If you are not the intended  
> recipient,
> and have received this message in error, please immediately return  
> this
> by email and then delete it.
>
>> -----Original Message-----
>> From: roger.keays [mailto:roger.keays@ninthavenue.com.au]
>> Sent: Thursday, January 04, 2007 4:09 PM
>> To: open-jpa-dev@incubator.apache.org
>> Subject: race condition in a transaction?
>>
>>
>> Hi,
>>
>> I'm just wondering if the following code could be subject to a race
>> condition when accessed by many threads
>>
>> em.getTransaction().begin();
>> bean.setCount(bean.getCount() + 1);
>> em.getTransaction().commit();
>>
>> My understanding is that it would be possible here for two
>> threads to set
>> the same value for the new count (given that each thread has
>> a different
>> em). Is that correct?
>>
>> Do I have to use an UPDATE query to make this function as expected?
>>
>> Thanks,
>>
>> Roger
>> -- 
>> View this message in context:
>> http://www.nabble.com/race-condition-in-a-transaction--tf29229
> 64.html#a8170503
>> Sent from the open-jpa-dev mailing list archive at Nabble.com.
>>
>>

Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:Craig.Russell@sun.com
P.S. A good JDO? O, Gasp!


RE: race condition in a transaction?

Posted by Patrick Linskey <pl...@bea.com>.
Assuming that you're using some sort of locking strategy (pessimistic or
optimistic), then only one tx will successfully commit.

You should only really use the UPDATE and DELETE JPQL statements for
bulk operations, not for day-to-day persistence work.

-Patrick

-- 
Patrick Linskey
BEA Systems, Inc. 

_______________________________________________________________________
Notice:  This email message, together with any attachments, may contain
information  of  BEA Systems,  Inc.,  its subsidiaries  and  affiliated
entities,  that may be confidential,  proprietary,  copyrighted  and/or
legally privileged, and is intended solely for the use of the individual
or entity named in this message. If you are not the intended recipient,
and have received this message in error, please immediately return this
by email and then delete it. 

> -----Original Message-----
> From: roger.keays [mailto:roger.keays@ninthavenue.com.au] 
> Sent: Thursday, January 04, 2007 4:09 PM
> To: open-jpa-dev@incubator.apache.org
> Subject: race condition in a transaction?
> 
> 
> Hi,
> 
> I'm just wondering if the following code could be subject to a race
> condition when accessed by many threads
> 
> em.getTransaction().begin();
> bean.setCount(bean.getCount() + 1);
> em.getTransaction().commit();
> 
> My understanding is that it would be possible here for two 
> threads to set
> the same value for the new count (given that each thread has 
> a different
> em). Is that correct?
> 
> Do I have to use an UPDATE query to make this function as expected?
> 
> Thanks,
> 
> Roger
> -- 
> View this message in context: 
> http://www.nabble.com/race-condition-in-a-transaction--tf29229
64.html#a8170503
> Sent from the open-jpa-dev mailing list archive at Nabble.com.
> 
>