[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [eclipselink-users] Odd optimistic lock exception behavior
|
Hello Noah,
The exception shows it is coming from a getSingleResult call on line 133, not an executeUpdate. Are there any other operations in this method that could result in the exception?
Best regards
Chris
On 2012-08-08, at 7:39 PM, Noah White <emailnbw@xxxxxxxxx> wrote:
>
> Hi folks,
>
> Hoping someone can shed some light on the following behavior. I have a no-interface stateless EJB 3.1 bean with the following method and injected JTA persistence context deployed to Glassfish 3.1.2 w/Eclipselink 2.3.2v20111125-r10461.
>
> This method is fired by an @Asynchronous method on another EJB. This other method is itself fired as the result of a JSF2 managed bean method call triggered by a form submit.
>
>
> @PersistenceContext(unitName = "PRODUCTION")
> private EntityManager entityManager;
>
> @TransactionAttribute(TransactionAttributeType.REQUIRES_NEW)
> pubic void resetAll() {
>
> ...
> Query q = entityManager.createQuery("DELETE FROM Foo");
> q.executeUpdate();
> Query p = entityManager.createQuery("UPDATE Bar b SET b.dirty=false WHERE b.dirty=true");
> p.executeUpdate
> ...
> }
>
> p.executeUpdate is throwing an OptimisticLockException. What's odd is that entity Bar does not have a @Version property or field whereas Foo does.
>
> As I mentioned the thread which triggered the @Asynchronous EJB method is a JSF managed bean method fired as the result of a POST. During the JSF lifecycle of the POST additional methods are call which update information on the page. This information involves the Foo entity. One thought was this had something to do with the TX in the above call and the TX in the managed bean that is fetching Foo information during the post POST render lifecycle and that this was being caused by the TX isolation level. However, I confirmed that the iso level is READ_COMMITED so I don't see that as being the problem.
>
> Interestingly, this only happens if there are no Foo entities, that is to say when the Foo table is empty. Once there is at least one row in Foo this method will execute trouble free without the OLEX being thrown. I am guessing this is because the DELETE returns 0 updated rows since the table is empty and this is interpreted as an OLEX but why is this not being triggered/thrown when q.executeUpdate is called as opposed to when p.executeUpdate is being called? Could this be due to the fact I am using batch-writing and the UPDATE is what is actually triggering the flush?
>
> This is against an Oracle 10g DB w/the ojdbc6.jar thin driver. My persistence.xml also has the following which may (or may not) be relevant:
>
> eclipselink.jdbc.native-sql "true"
> eclipselink.jdbc.batch-writing "Oracle-JDBC"
>
> This is the stack trace:
>
> Caused by: javax.persistence.OptimisticLockException: Exception [EclipseLink-5011] (Eclipse Persistence Services - 2.3.2.v20111125-r10461): org.eclipse.persistence.exceptions.OptimisticLockException
> Exception Description: One or more objects cannot be updated because it has changed or been deleted since it was last read
> at org.eclipse.persistence.internal.jpa.EntityManagerImpl.flush(EntityManagerImpl.java:782)
> at org.eclipse.persistence.internal.jpa.EJBQueryImpl.performPreQueryFlush(EJBQueryImpl.java:1298)
> at org.eclipse.persistence.internal.jpa.EJBQueryImpl.executeReadQuery(EJBQueryImpl.java:434)
> at org.eclipse.persistence.internal.jpa.EJBQueryImpl.getSingleResult(EJBQueryImpl.java:773)
> at com.abc.FooBean.resetAll(FooBean.java:133)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:601)
> at org.glassfish.ejb.security.application.EJBSecurityManager.runMethod(EJBSecurityManager.java:1052)
> at org.glassfish.ejb.security.application.EJBSecurityManager.invoke(EJBSecurityManager.java:1124)
> at com.sun.ejb.containers.BaseContainer.invokeBeanMethod(BaseContainer.java:5388)
> at com.sun.ejb.EjbInvocation.invokeBeanMethod(EjbInvocation.java:619)
> at com.sun.ejb.containers.interceptors.AroundInvokeChainImpl.invokeNext(InterceptorManager.java:800)
> at com.sun.ejb.EjbInvocation.proceed(EjbInvocation.java:571)
> at org.jboss.weld.ejb.SessionBeanInterceptor.aroundInvoke(SessionBeanInterceptor.java:42)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:601)
> at com.sun.ejb.containers.interceptors.AroundInvokeInterceptor.intercept(InterceptorManager.java:861)
> at com.sun.ejb.containers.interceptors.AroundInvokeChainImpl.invokeNext(InterceptorManager.java:800)
> at com.sun.ejb.EjbInvocation.proceed(EjbInvocation.java:571)
> at com.sun.ejb.containers.interceptors.SystemInterceptorProxy.doAround(SystemInterceptorProxy.java:162)
> at com.sun.ejb.containers.interceptors.SystemInterceptorProxy.aroundInvoke(SystemInterceptorProxy.java:144)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:601)
> at com.sun.ejb.containers.interceptors.AroundInvokeInterceptor.intercept(InterceptorManager.java:861)
> at com.sun.ejb.containers.interceptors.AroundInvokeChainImpl.invokeNext(InterceptorManager.java:800)
> at com.sun.ejb.containers.interceptors.InterceptorManager.intercept(InterceptorManager.java:370)
> at com.sun.ejb.containers.BaseContainer.__intercept(BaseContainer.java:5360)
> at com.sun.ejb.containers.BaseContainer.intercept(BaseContainer.java:5348)
> at com.sun.ejb.containers.EJBLocalObjectInvocationHandler.invoke(EJBLocalObjectInvocationHandler.java:214)
> ... 39 more
> Caused by: Exception [EclipseLink-5011] (Eclipse Persistence Services - 2.3.2.v20111125-r10461): org.eclipse.persistence.exceptions.OptimisticLockException
> Exception Description: One or more objects cannot be updated because it has changed or been deleted since it was last read
> at org.eclipse.persistence.exceptions.OptimisticLockException.batchStatementExecutionFailure(OptimisticLockException.java:79)
> at org.eclipse.persistence.internal.databaseaccess.ParameterizedSQLBatchWritingMechanism.executeBatchedStatements(ParameterizedSQLBatchWritingMechanism.java:148)
> at org.eclipse.persistence.internal.databaseaccess.DatabaseAccessor.writesCompleted(DatabaseAccessor.java:1707)
> at org.eclipse.persistence.internal.sessions.AbstractSession.writesCompleted(AbstractSession.java:3836)
> at org.eclipse.persistence.internal.sessions.UnitOfWorkImpl.writesCompleted(UnitOfWorkImpl.java:5520)
> at org.eclipse.persistence.internal.sessions.RepeatableWriteUnitOfWork.writeChanges(RepeatableWriteUnitOfWork.java:448)
> at org.eclipse.persistence.internal.jpa.EntityManagerImpl.flush(EntityManagerImpl.java:780)
> ... 73 more
> |#]
>
> TIA,
>
> -Noah
>
>
>
>
> _______________________________________________
> eclipselink-users mailing list
> eclipselink-users@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/eclipselink-users
