Michael, it looks like you're doing some custom asynchronous continuation, and
the moment in which the new transaction is started (i.e. the jBPM context
created) isn't related at all of the old transaction, which in a sense
'spawned' it - am I reading that correctly?
We have been doing something similar in our system (we're still using 3.1.4 for
now, I guess you have a similar predicament in which upgrading an existing
system just is easier said than done), and we encountered the same inconsistent
and unpredictable SOSE occurrences.
The problem was that we used an indeterministic strategy for creating a new
jBPM context in a new thread - we didn't wait for the old one to be closed and
were 'hoping for the best' - unknowingly at first, of course.
We found a solution by making sure the new transaction is started only after
the old one has ended: digging a little beyond the jBPM API into the Hibernate
API, in which the org.hibernate.Transaction interface has the possibility to
register a callback object (which must implement the
javax.transaction.Synchronization interface). The latter object then is called
before and after the two-phase-commit, and we used this last call as a starting
point for the new transaction.
>From within an opened transaction we use something like this:
| jbpmContext.getSession().getTransaction().registerSynchronization(new
Synchronization() {
| public void beforeCompletion() {
| // We're not using this one ourselves...
| }
|
| public void afterCompletion(int status) {
| // Here we spawn a new thread which can safely open its own
jBPM context...
| }
| });
|
Hope this helps you out a little bit!
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4257185#4257185
Reply to the post :
http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4257185
_______________________________________________
jboss-user mailing list
[email protected]
https://lists.jboss.org/mailman/listinfo/jboss-user
