openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dain Sundstrom <d...@iq80.com>
Subject Re: What causes an optimistic exception?
Date Fri, 05 Jan 2007 17:12:05 GMT
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:dain@iq80.com]
>> 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
>>


Mime
View raw message