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:[EMAIL PROTECTED] > 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. > >