do a flush before you close the JbpmContext
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4038766#4038766
Reply to the post :
http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4038766
___
jboss-user
I found the '"why" of the stack trace mentioned in the previous post. A lost
e.printStackTrace in the close() methode in org.jbpm.svc.Service at line 213
(for jbpm-3.1.4).
Johan
ps: does this need an entry in JIRA?
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopi
In the meanwhile I've implemented this approach. And it solves the problem.
But I can't catch the exception very early on. So my process produces ugly
stack traces upon unsuccesful commits.
I'm not sure whether replace the DbPersistenceService(Factory) (through the
service definition in the jb
Thank you very very much for this very clear answer! Much appreciated.
Johan
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4013497#4013497
Reply to the post :
http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4013497
_
There are two approaches for concurrent task assignment in particular and
database access in general: pessimistic locking and optimistic control.
In the first approach, you lock the task instance
(jbpmContext.getSession().lock(taskInstance, LockMode.UPGRADE) before you
update it. The first tran
Me again...
Hmmm, is my question so stupid? If so, I gladly settle for a "look at thread nr
XXX ..." type of reply :) Just shoot
How are other people handling this then? With carefully crafted assignment
handlers?
As you can see I'm desperately in need of some jBPM wisdom here ;)
Best regard
