openjpa-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From ljnelson <ljnel...@gmail.com>
Subject Re: Optimistic lock problem
Date Wed, 02 Mar 2011 18:19:56 GMT
Note that your persistence unit you have extracted below still includes
openjpa.RuntimeUnenhancedClasses set to supported.  That can disable
enhancement.  I don't know what this property does if dynamic enhancement is
also in effect.

Best,
Laird

On Wed, Mar 2, 2011 at 12:45 PM, KAWANAKA Shinya-2 [via OpenJPA] <
ml-node+6081932-1153516800-155969@n2.nabble.com> wrote:

> Rick,
>
> I used runtime enhancement at that time. The below is extracted from my
> persistence.xml (password etc. are omitted.)
> # DataCache and QueryCache are off here, but I tried all the possibilities.
>
>
>
>
>   <persistence-unit name="postgres">
>
> <provider>org.apache.openjpa.persistence.PersistenceProviderImpl</provider>
>
>     <class>entity.Questionnaire</class>
>
>     <properties>
>       <property name="openjpa.ConnectionDriverName"
> value="org.apache.commons.dbcp.BasicDataSource"/>
>       <property name="openjpa.ConnectionProperties"
> value="DriverClassName=org.postgresql.Driver,Url=jdbc:postgresql:omitted,Username=omitted,Password=omitted"/>
>
>       <property name="openjpa.Log" value="DefaultLevel=WARN, Tool=INFO"/>
>
>       <property name="openjpa.jdbc.DBDictionary" value="postgres" />
>
>       <property name="openjpa.jdbc.SynchronizeMappings"
> value="buildSchema(SchemaAction='drop,add')" />
>       <property name="openjpa.RuntimeUnenhancedClasses" value="supported"/>
>
>
>       <property name="openjpa.DataCache" value="false"/>
>       <property name="openjpa.QueryCache" value="false"/>
>       <property name="openjpa.RemoteCommitProvider" value="sjvm"/>
>     </properties>
>
>   </persistence-unit>
>
> On Mar 3, 2011, at 02:11 , Rick Curtis wrote:
>
> > Kawanaka -
> >
> > I'm going to start with my typical first question.... How are you
> enhancing
> > your Entities? Can you post the contents of your persistence.xml file?
> >
> > Thanks,
> > Rick
> >
> > On Wed, Mar 2, 2011 at 10:31 AM, KAWANAKA Shinya <[hidden email]<http://user/SendEmail.jtp?type=node&node=6081932&i=0&by-user=t>>wrote:
>
> >
> >> Hi list,
> >>
> >> I encountered the weird situation that an optimistic lock violation
> >> happened. I would like you to judge this is my fault or a bug.
> >>
> >> First I created an entity listed on here (
> https://gist.github.com/851075).
> >> Then I wrote several tests that used the entity. In the following test,
> an
> >> optimistic lock violation happened.
> >>
> >> === CODE STARTS HERE ===
> >>       EntityManager em = emf.createEntityManager();
> >>       {
> >>           em.getTransaction().begin();
> >>           for (int i = 0; i < 10; ++i) {
> >>               Questionnaire q = new Questionnaire("id" + i, "eventId",
> >> "question", i, "answerText");
> >>               em.persist(q);
> >>           }
> >>           // em.flush(); // (1)
> >>           em.getTransaction().commit();
> >>       }
> >>
> >>       {
> >>           em.getTransaction().begin();
> >>           // em.flush(); // (3)
> >>           Query q = em.createQuery("DELETE FROM Questionnaires t");
> >>           q.executeUpdate();
> >>           em.getTransaction().commit(); // (2)
> >>       }
> >>
> >>       em.close();
> >> === CODE END HERE ===
> >>
> >> In (2) the exception happened. The stack trace is attached at the last.
> >> When I changed the field type of 'questionNo' to Integer (int ->
> Integer),
> >> the violation did not happen.
> >>
> >> Some one advised me to use flush() at (1), but it did not help.
> >>
> >> When I added (3) and traced the function, I found that
> >> ImplHelper.getUpdateField(sm) in
> AbstractUpdateManager#populateRowManager
> >> returned a dirty flag that said the 'questionNo' was dirty.
> >>
> >> === CODE HERE ===
> >>           } else if ((dirty = ImplHelper.getUpdateFields(sm)) != null) {
>
> >>               update(sm, dirty, (ClassMapping) sm.getMetaData(), rowMgr,
>
> >>                   store, customs, false);
> >> === END ===
> >>
> >> I only used a single thread, so I don't think the entities were changed
> in
> >> the other threads. (Remember that the field type of 'questionNo' was
> changed
> >> to Integer, the code worked.)
> >>
> >> Does anyone know why the violation happens?
> >>
> >> My environment is
> >> Mac OS X Snow leopard, Sun Java 6, and OpenJPA-2.0.1.
> >>
> >>
> >>
> >> Exception in thread "main" <openjpa-2.0.1-r422266:989424 fatal store
> error>
> >> org.apache.openjpa.persistence.RollbackException: Optimistic locking
> errors
> >> were detected when flushing to the data store.  The following objects
> may
> >> have been concurrently modified in another transaction:
> >> [entity.Questionnaire-id3, entity.Questionnaire-id1,
> >> entity.Questionnaire-id5, entity.Questionnaire-id2,
> >> entity.Questionnaire-id6, entity.Questionnaire-id0,
> >> entity.Questionnaire-id8, entity.Questionnaire-id9,
> >> entity.Questionnaire-id4, entity.Questionnaire-id7]
> >>       at
> >>
> org.apache.openjpa.persistence.EntityManagerImpl.commit(EntityManagerImpl.java:584)
>
> >>       at client.Test.run(Test.java:44)
> >>       at client.Test.main(Test.java:17)
> >> Caused by: <openjpa-2.0.1-r422266:989424 nonfatal store error>
> >> org.apache.openjpa.persistence.OptimisticLockException: Optimistic
> locking
> >> errors were detected when flushing to the data store.  The following
> objects
> >> may have been concurrently modified in another transaction:
> >> [entity.Questionnaire-id3, entity.Questionnaire-id1,
> >> entity.Questionnaire-id5, entity.Questionnaire-id2,
> >> entity.Questionnaire-id6, entity.Questionnaire-id0,
> >> entity.Questionnaire-id8, entity.Questionnaire-id9,
> >> entity.Questionnaire-id4, entity.Questionnaire-id7]
> >>       at
> >>
> org.apache.openjpa.kernel.BrokerImpl.newFlushException(BrokerImpl.java:2291)
>
> >>       at
> org.apache.openjpa.kernel.BrokerImpl.flush(BrokerImpl.java:2139)
> >>       at
> >> org.apache.openjpa.kernel.BrokerImpl.flushSafe(BrokerImpl.java:2037)
> >>       at
> >>
> org.apache.openjpa.kernel.BrokerImpl.beforeCompletion(BrokerImpl.java:1955)
> >>       at
> >>
> org.apache.openjpa.kernel.LocalManagedRuntime.commit(LocalManagedRuntime.java:81)
>
> >>       at
> org.apache.openjpa.kernel.BrokerImpl.commit(BrokerImpl.java:1479)
> >>       at
> >>
> org.apache.openjpa.kernel.DelegatingBroker.commit(DelegatingBroker.java:925)
>
> >>       at
> >>
> org.apache.openjpa.persistence.EntityManagerImpl.commit(EntityManagerImpl.java:560)
>
> >>       ... 2 more
> >> Caused by: <openjpa-2.0.1-r422266:989424 nonfatal store error>
> >> org.apache.openjpa.persistence.OptimisticLockException: An optimistic
> lock
> >> violation was detected when flushing object instance
> >> "entity.Questionnaire-id3" to the data store.  This indicates that the
> >> object was concurrently modified in another transaction.
> >> FailedObject: entity.Questionnaire@72940b84
> >>       at
> >>
> org.apache.openjpa.jdbc.kernel.PreparedStatementManagerImpl.flushAndUpdate(PreparedStatementManagerImpl.java:123)
>
> >>       at
> >>
> org.apache.openjpa.jdbc.kernel.BatchingPreparedStatementManagerImpl.flushAndUpdate(BatchingPreparedStatementManagerImpl.java:81)
>
> >>       at
> >>
> org.apache.openjpa.jdbc.kernel.PreparedStatementManagerImpl.flushInternal(PreparedStatementManagerImpl.java:99)
>
> >>       at
> >>
> org.apache.openjpa.jdbc.kernel.PreparedStatementManagerImpl.flush(PreparedStatementManagerImpl.java:87)
>
> >>       at
> >>
> org.apache.openjpa.jdbc.kernel.ConstraintUpdateManager.flush(ConstraintUpdateManager.java:550)
>
> >>       at
> >>
> org.apache.openjpa.jdbc.kernel.ConstraintUpdateManager.flush(ConstraintUpdateManager.java:107)
>
> >>       at
> >>
> org.apache.openjpa.jdbc.kernel.BatchingConstraintUpdateManager.flush(BatchingConstraintUpdateManager.java:59)
>
> >>       at
> >>
> org.apache.openjpa.jdbc.kernel.AbstractUpdateManager.flush(AbstractUpdateManager.java:103)
>
> >>       at
> >>
> org.apache.openjpa.jdbc.kernel.AbstractUpdateManager.flush(AbstractUpdateManager.java:76)
>
> >>       at
> >>
> org.apache.openjpa.jdbc.kernel.JDBCStoreManager.flush(JDBCStoreManager.java:731)
>
> >>       at
> >>
> org.apache.openjpa.kernel.DelegatingStoreManager.flush(DelegatingStoreManager.java:131)
>
> >>       ... 9 more
> >>
> >>
> >> --
> >> Kawanaka Shinya <[hidden email]<http://user/SendEmail.jtp?type=node&node=6081932&i=1&by-user=t>>
>
> >> http://mayah.jp/
> >>
> >>
> >>
> >>
> >>
> >>
> >>
>
> --
> Kawanaka Shinya <[hidden email]<http://user/SendEmail.jtp?type=node&node=6081932&i=2&by-user=t>>
>
> http://mayah.jp/
>
>
>
>
>
>
>
> ------------------------------
>  If you reply to this email, your message will be added to the discussion
> below:
>
> http://openjpa.208410.n2.nabble.com/Optimistic-lock-problem-tp6081639p6081932.html
>  To start a new topic under OpenJPA Users, email
> ml-node+208411-242897574-155969@n2.nabble.com
> To unsubscribe from OpenJPA Users, click here<http://openjpa.208410.n2.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=208411&code=bGpuZWxzb25AZ21haWwuY29tfDIwODQxMXw4OTk4MzY1OTI=>.
>
>


--
View this message in context: http://openjpa.208410.n2.nabble.com/Optimistic-lock-problem-tp6081639p6082054.html
Sent from the OpenJPA Users mailing list archive at Nabble.com.
Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message