Digged into it a bit further.
Seems to me that there are cases for which FORCE lock will never work.
Let me try to explain:
If you have a process with a fork join where the parallel branches contain a
node which performs a query.
If you can run from start to the join in the same transaction
mputz wrote :
| please try to explicitly set the lock mode on the join:
| join name=join1 lock=UPGRADE
| and let us know how it works for you.
Martin, thanks, this worked. Is this a recommended way of dealing with all
joins or is it just a temporary workaround (haven't seen support for
I stumbled into the same problem (and some others) while trying to upgrade.
Does this mean that when upgrading to the 3.3 version of jbpm, all process
definition with joins need to be changed (lockmode upgrade needs to be added).
By default lockmode seems to be 'force' which gives problems with
Ok, here it goes the way we made it work.
All the nodes are async='true'
All the forks are async='true'
All the joins are async='true' and lock='UPGRADE'
The graph has to be legal (have certain simmetry) As explained in
http://www.jboss.com/index.html?module=bbop=viewtopict=147553. If
Hi Ronald,
I really appreciate all suggestions (it doesn't matter if they are a final
solution or just a hack to make it work).
I have just tried to introduce a delay of 8 seconds in one of the actions of
the parallel nodes, and I still get the SOE.
I believe the issue is related with
Thanks for trying... I'm not sure the fork has the same lock options, I should
look in the code.
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4197417#4197417
Reply to the post :
http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4197417
I have a similar problem, although in my case the nodes have async='true'.
The exception I get is
| org.hibernate.StaleObjectStateException: Row was updated or deleted by
another transaction (or unsaved-value mapping was incorrect):
[org.jbpm.graph.exe.Token#48]
| at
Petr,
please try to explicitly set the lock mode on the join:
join name=join1 lock=UPGRADE
and let us know how it works for you.
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4197120#4197120
Reply to the post :
Hi Ronald,
Thanks a lot for the suggestion. With async=exclusive I don't get any
exception at all. Hoever, the actions inside the nodes, are executed
sequentially and not in parallel.
I am deploying the framework from a class, and have running the JobExecutor
with several threads in a
I did not want to suggest it is a solution but can it be your actions are quick
to finish after each other? Can you post what they do? Or maybe make a test
that have them end with seconds in between?
View the original post :
Yes, could very well be the case. jBPM 3.3 has no QA setup for Oracle (yet) so
that might be why it was missed. Although Tom states in JBPM-1772 that he'll
re-introduce the flush, it does not seem to be in the code. Please file a
re-open https://jira.jboss.org/jira/browse/JBPM-1085 and refer
I'll re-open the JIRA, thanks. I tried to put back in the flush() into thetrunk
code but getting this exception:
14:57:10,318 ERROR [GraphElement] action threw exception: collection
[org.jbpm.bytes.ByteArray.byteBlocks] was not processed by flush()
| org.hibernate.AssertionFailure: collection
Couldn't re-open the issu so reated a new one:
https://jira.jboss.org/jira/browse/JBPM-1886
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4191779#4191779
Reply to the post :
http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4191779
13 matches
Mail list logo
