I have a spring MVC application running on the application server. Each request to the application results in Hibernate calling the entityManager.merge() to update a row in the database.
I run a test today sending in multiple requests and noticed that something i get the following error:
javax.persistence.OptimisticLockException
at org.jboss.resteasy.core.SynchronousDispatcher.handleApplicationException(SynchronousDispatcher.java:340) [resteasy-jaxrs-2.3.1.GA.jar:]
at org.jboss.resteasy.core.SynchronousDispatcher.handleException(SynchronousDispatcher.java:214) [resteasy-jaxrs-2.3.1.GA.jar:]
at org.jboss.resteasy.core.SynchronousDispatcher.handleInvokerException(SynchronousDispatcher.java:190) [resteasy-jaxrs-2.3.1.GA.jar:]
at org.jboss.resteasy.core.SynchronousDispatcher.getResponse(SynchronousDispatcher.java:540) [resteasy-jaxrs-2.3.1.GA.jar:]
at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:502) [resteasy-jaxrs-2.3.1.GA.jar:]
at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:119) [resteasy-jaxrs-2.3.1.GA.jar:]
at org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:208) [resteasy-jaxrs-2.3.1.GA.jar:]
at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:55) [resteasy-jaxrs-2.3.1.GA.jar:]
at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:50) [resteasy-jaxrs-2.3.1.GA.jar:]
at javax.servlet.http.HttpServlet.service(HttpServlet.java:847) [jboss-servlet-api_3.0_spec-1.0.0.Final.jar:1.0.0.Final]
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:329) [jbossweb-7.0.10.Final.jar:]
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:248) [jbossweb-7.0.10.Final.jar:]
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:275) [jbossweb-7.0.10.Final.jar:]
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:161) [jbossweb-7.0.10.Final.jar:]
at org.jboss.as.jpa.interceptor.WebNonTxEmCloserValve.invoke(WebNonTxEmCloserValve.java:50) [jboss-as-jpa-7.1.0.Final.jar:7.1.0.Final]
at org.jboss.as.web.security.SecurityContextAssociationValve.invoke(SecurityContextAssociationValve.java:154) [jboss-as-web-7.1.0.Final.jar:7.1.0.Final]
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:155) [jbossweb-7.0.10.Final.jar:]
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) [jbossweb-7.0.10.Final.jar:]
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) [jbossweb-7.0.10.Final.jar:]
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:368) [jbossweb-7.0.10.Final.jar:]
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:877) [jbossweb-7.0.10.Final.jar:]
at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:671) [jbossweb-7.0.10.Final.jar:]
at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:930) [jbossweb-7.0.10.Final.jar:]
at java.lang.Thread.run(Thread.java:619) [rt.jar:1.6.0_20]
To be able to resolve the above i need to understand the following:
-
How are the requests handled on the application server? Is the case that each request is processed by its own thread?
-
Looking at the error i noticed that they were referred to as (http–10.10.4.16-8080-1) and (http–10.10.4.16-8080-7). Is the number at the end the thread number that processed the request?
-
The optimistiLockException suggests that there was an attempt to update the same message before JPA/Hibernate issued a commit. If i put the relevant code in a synchronized block, how do i ensure that the order the requests came in is the order they are processed when the synchronized block is available?
-
Is there a way to instruct JPA/Hibernate to not attempt to update the message if there are uncommitted changes?
Thanks
The fixes available to you depend on how you’ve architectured your tiers and where the entity you’re merging comes from. Is the detached entity being assembled by the spring data binder, or stored on the web session, or are you fetching an entity from the database and making changes to it at the time the request arrives?
They are handled by a thread pool. So each request does not get “its own” thread, but at any given time each active request is being processed by a seoarate thread, yes. (Or in a queue waiting for one to free.)
The whole thing is the name of the thread. Tomcat puts numbers at the end to make them unique, but that # doesn’t have any particular meaning other than an arbitrary sequential string assigned by tomcat.
If order matters you will need to put them in some kind of a queue before processing. Synchronization makes no promises about the order waiting threads execute. If this process is a must-not-fail, consider using a pessimistic lock in the database rather than synching up on the app server. Some other thread using the table might not bother sycnhing and cause the exception anyway.
Not really, there isn’t any direct way to check if an entity has pending updates in some other session’s in memory cache. The OptimisticLock check is the mechanism for knowing if someone else made a change.