I do not believe I am. Each method results in the following basic
code structure:
Set Thread Context CL (needed for JPA)
Start Tx
EntityManager em = emf.createEntityManager()
if (entityManager instanceof OpenJPAEntityManager) {
OpenJPAEntityManager openjpaEM = (OpenJPAEntityManager)
entityManager;
openjpaEM.addLifecycleListener(new OpenJPALifecycleListener
(), (Class[])null);
}
Object entity = em.find(beanClass, primaryKey);
entity.doSomething();
Complete Tx
Reset Thread Context CL
One additional thing, my life cycle listener calls ejbActivate and
ejbLoad on the entity when afterLoad fires, and calls ejbStore on the
entity when beforeStore fires.
-dain
On Jan 5, 2007, at 9:01 AM, Patrick Linskey wrote:
Are you using detachment and merging in your test?
-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: Dain Sundstrom [mailto:[EMAIL PROTECTED]
Sent: Thursday, January 04, 2007 6:20 PM
To: open-jpa-dev@incubator.apache.org
Subject: Re: What causes an optimistic exception?
On Jan 4, 2007, at 1:12 PM, Michael Dick wrote:
By default OpenJPA uses optimistic transactions (ie the
transaction
does not
lock database records). Since the database records aren't locked
there is a
chance that a second transaction can modify the record before the
first one
completes. There's a better explanation in the OpenJPA manual here :
http://incubator.apache.org/openjpa/docs/openjpa-0.9.6-incubating/
manual/manual.html#jpa_overview_trans_types.
The OptimisticException you're seeing in the log is thrown when
OpenJPA
detects that a record has been changed by another thread. The
exception
should be thrown back to the transaction manager though so there
might be a
bug there, or something is intercepting it.
Does the problem occur when you run one test at a time, or does it
only
occur if you run several of them at once? If you're running more
than one
test and they touch the same rows of the database, that might
explain why
you're getting the exception (but not why it isn't making it back
to the
app).
This is a single threaded test.
That's my first guess. If you can easily reproduce the problem it
might help
to turn on OpenJPA tracing and see if that shows two transactions
using the
same entity.
I'll take a look.
-dain
