Hello,
OK, I found a post from Tom Baeyens about Job Executor. I understand now that there is no jobs locking but only hibernate optimistic concurrence control using versionning on jobs data.
But still, I do not understand why there would be concurrence (and so sometime collision) in my case. I have only one JobExecutor, so there can be only one thread to acquire a job end execute it, even if I have two process instances (or more) running at the same time. Is it right ? In this case, I don't see what could be the problem. Could you please help me ?
LF
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4220071#4220071
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4220071
Hey,
I have two process instances, each one coming from a different process definition. Each process has a timer and a couple of nodes, the last node has a transition back to the timer as a loop.
I start these two process instances. After a while, I get a hibernate stalestateexception (server logs) which occurs rarely and randomly. My question is why ? I do not see which data versionning could be the problem. Process instances are for me quite independent... and do not share data from database.
What can be the problem ? Is there a locking mechanism in JBPM for synchronizing jobs ? If yes, could you explain me in details how this locking works ?
Thanks
LF
Using jbpm3.2.3
Server : apache tomcat 5.5x
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4220050#4220050
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4220050
With all the online mobile devices it is indeed a very interesting addition.
On thing that I think would make it *a lot more secure* ;-) is using a hash as an ID instead of the actorid. (just like google does) This would require an additional field in the identity system I think
The usecases are nice btw, especially the pooled assignment stuff.
I'll see if I can get it to work on my Nokia N95 and/or iPod Touch.
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4220024#4220024
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4220024
interupting long runnning things is not different in jBPM then in any other java application.
Make actionhandlers that can receive events (non-jbpm events) and act upon them. Have your timer send one of these events then..
But it might be a nice addition to jBPM I think to be able to cancel long running async things when they are already running (timers can be cancelled when not started yet)
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4220021#4220021
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4220021
I don't say you need a database to run things, I just say that the jbpm container resolves subprocess dependencies when you *deploy* them. Since you do not deploy them, there is no resolver and you have to associate the two yourself.
the 'I doudbt you would' success was indeed a bit harsh and not directed at you, but a remark in general which I now think is not completely valid. What I wanted to express is why not just associate the two via an api if you know they are related instead of trying to make resolvers or whatever.
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4220020#4220020
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4220020
