[JBoss jBPM] - JBPM - concurrent process execution fails
by efip10
In my deployment, I use a pool of MDBs to start a number of workflows.
The workflows progress from node to node, collecting objects in hibernate session, and at some state they fire a message to (another) queue. After that, the finally { jbpmContext.close() } is reached, and the session begins to flush.
In the meantime, in some other place in the galaxy, another pool of MDBs receives the messages and starts processing on them. First thing that is done is jbpmContext.loadProcessInstanceForUpdate(id); at which state the execution fails with Hibernate exceptions, like
org.hibernate.HibernateException: null index column for collection: org.jbpm.graph.exe.ProcessInstance.instances and org.hibernate.LazyInitializationException: illegal access to loading collection
At this stage, I cannot even end or cancel my token, since the processInstance is not loaded correctly.
As a result, my workflow stays in zombie state and actually never ends.
We use JBoss 4.0.5, Hibernate, Spring, MySQL (tried with all isolation levels) and jBPM 3.2.
Any suggestions on how to make sure the processInstance is fully saved to the DB before I read it? No mutexes can help here because of clustered deployment.
Thanks in advance.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4063578#4063578
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4063578
19Â years
[Installation, Configuration & DEPLOYMENT] - Re: How to switch from JTA to JTS in JBoss AS 4.2.0.GA?
by kevinpauli
"jhalliday" wrote : > You don't need JTS for that unless you are using more than one JBoss instance.
Then I must be doing something wrong or have a bad misconception.
I have a transaction in which I write some rows to the database and send a JMS message. Sometimes I am getting a race condition where the MDB that is recieving the message fires up and looks in the database and can't find the new rows; the original transaction is not committed yet. If I step through in debug mode, or make the MDB sleep for a couple seconds before hitting the database, the race condition goes away.
I thought the whole point of having JMS participate in a transaction was so that the message would not be placed on the queue (and therefore not be consumed by the receiving MDB) until the transaction was complete?
(BTW, my JMS provider is JBossMQ, which is the default configured for JBoss AS 4.2.0.GA. would switching to JBoss Messaging make a difference?)
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4063564#4063564
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4063564
19Â years
[JBoss Seam] - Re: flushMode= MANUAL, when does commit happen? And other qu
by Delphi's Ghost
AFAIK, you cannot perform multiple data entry conversations in a nested fashion without having an all-or-nothing problem with regards to saving the data.
The problem is that each nested conversation uses the same persistence context, and when you flush for a nested conversation, you are flushing for all conversations using that persistence context (which includes all parent and child conversations).
The conclusion I reached was that unfortunately, the nested conversation model was only good for browsing/navigating data due to the fact that it shares the persistence context. The Seam Issues example which was the only example to have editable pages in nested conversations was removed from the latest release (hope they re-write it to show how it should be done).
Here are a couple of threads related to persistence contexts and nested conversations:
http://www.jboss.com/index.html?module=bb&op=viewtopic&t=111681
http://www.jboss.com/index.html?module=bb&op=viewtopic&t=111384
However, thinking about your problem more, you may be able to do something like :
Start root conversation (with flushmode = automatic)
Create mother entity
Persist mother entity
Set the entityManager flush mode to Manual
At this point, you are in a manual flush mode, with the mother entity already created and persisted. If the child item also has child items, then you are in a sticky problem. Also this solution doesn't handle the problem of :
Edit Mother Entity
Add child
Edit child
Flush entity manager to save child -> Ooops, we just accidentally saved the changes to the mother also since the child is edited in a nested conversation, and we flushed the shared persistence context.
Also, if your 'add child' or 'edit child' links could be opened in new windows, then you could have accidental flushes in each conversation when you just meant to save and flush one instance of the child editor.
As for rolling back the mother entity in the event of a conversation timeout...
If you have a flag called isNew which indicates whether it is a new entity or not, you can write a cancel changes procedure, something like:
| String cancelChanges() {
| if (isNew) {
| em.remove(motherItem);
| } else {
| em.refresh(motherItem);
| }
| }
|
|
I don't know the feasability of this, perhaps someone with more knowledge than me can comment, but you have a method marked with the @Destroy annotation, you could just call the cancel changes method from there if it has not already been saved (i.e. isNew is still true).
This might be icky, but come to think of it, I'm wondering if this is a pretty handy pattern because what the conversation times out and you have made edits to the entity involved? Those edits could sit around in the persistence context after the conversation has timed out. Should the entity be refreshed because the persistence context might be re-used with the dirty object in it?
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4063562#4063562
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4063562
19Â years