sorry, not sure yet. i was busy doing other stuff. i will have to discuss this
with my colleagues who are more into hibernate. i will tell you when i know.
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4164392#4164392
Reply to the post :
http://www.jboss.c
"kukeltje" wrote : anonymous wrote : jBPM swallows the
StaleObjectStateException causing the calling code not to notice that the
operation failed. Afaik, that can be configured in jBPM 3.2.3. Please have a
look in the docs
|
i'm afraid not. i've been on this thing several hours. the config
Ah okay. I did not go deep into Tasks yet, cause it was not necessary in our
workflows. The timout seems to be a good solution for the
forever-locking-problem.
Can you please give me more details on your solution? I think i'm gonna try it,
too.
cheers
View the original post :
http://www.jbos
-> resources: i'm sorry, i'm new to the discussion board, too. so i have no
idea where to find the original discussion thread.
-> exception: the exception is caught after all in org.jbpm.svc.Services in
Line 226. The original Exception is caught earlier but gets wrapped into a
JbpmPersistenceEx
as i see it, it works/fails like this:
1a. thread 1 opens a jbpmContext and a process instance
1b. thread 2 opens a jbpmContext and the same process instance
2a. thread 1 passes data to the process instance and gives a signal()
2b. thread 2 also passes data to the process instance and gives a sign
I'm facing the same problem: jBPM swallows the StaleObjectStateException
causing the calling code not to notice that the operation failed.
I figured out a workaround, but I'm not sure yet, whether it's proper or not.
The idea is to do the hibernate-commit() by myself and so be able to receive
t
