anonymous wrote : | The context is *always* closed by yourself. In a longer running process, the wait state will return the thread of control to the caller, which means that you can close the context if needed. | | This is not a bad design. The Hibernate session mechanism works exactly the same way. |
Usually, commits occur along transactional boundaries, be it at the end of a service call or the end of a web request, etc. As part of committing the transaction, Hibernate's flush/commit occurs. Note: flush can occur at any time if Hibernate deems it necessary. My point is that if jBPM creates a Timer object but does not commit the transaction then the JobExecutor will find the transaction by means of the second level cache and update it. At this point the JobExecutor will attempt a commit, but the main thread will not. This causes a lock exception in jBPM. Also, this would not occur if the main thread committed after the creation of a timer, or better yet, any change of state in the process execution. I'll file it as a bug and see what happens. What did you mean by: anonymous wrote : | the wait state will return the thread of control to the caller View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4181844#4181844 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4181844 _______________________________________________ jboss-user mailing list [email protected] https://lists.jboss.org/mailman/listinfo/jboss-user
