openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Patrick Linskey" <plins...@bea.com>
Subject RE: race condition in a transaction?
Date Fri, 05 Jan 2007 06:43:35 GMT
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.
> 
> 

Mime
View raw message