I do not use pessimistic locking because it is necassary to synchronize against the parent parent parent.... process instance because a signal anywhere in the process can cause data changes up in the hierachy. So I would have to make a loadInstanceForUpdate on the parent instance.
Using pessimitic locking on the row level causes deadlock situations in the database where orcale throws exceptions then.
I decided to do it with a jboss cache so that i can relase the jbpmcontext during the wait for the lock in order not to hold the the database resources during waiting. But the loadInstnaceForUpdate would definitly be an option I think.
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4208880#4208880
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4208880
Hi guys,
what is the current status of an eEJB3 enterprise module (form jbpm 3)? It was discussed quite often already, but nothing is done on this yet, right? Or did I miss any code?
For a current project I will develop it anyway, does it make sense to commit it for others? I know a couple of projects which developed their own EJB3 bean and I get the question in trainings quite often. So I think it would make sense for a lot of people, more than the "old" EJB 2.1 stuff...
What do you guys think?
Could it be put in 3.3. to avoid productization/support effort?
Cheers
Bernd
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4208878#4208878
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4208878
@roschmel: Okay, now its a bit clearer. Why don't you use hibernate pessimistic locking in this case? And: With async=true, couldn't you get completly rid of the problematic situations if you use it often enough?
Alex wrote : An ExecuteJobsCommand is constructed with the exclusive job IDs and sent to the command queue. The command executor then executes the jobs serially.
Couldn't this lead to the behavior of a repeating timer creating jobs which cannot be processed as fast as created (assume the system is very utilized)? This is why we normally decided against executing timer stuff over JMS.
Or what do you think?
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4208876#4208876
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4208876