[JBoss jBPM] - Re: How to best control access from multiple threads to a Pr
by jse
AmiraTalbi
You exactly understand the problem... and you are right, it is not specifically a jBpm issue. There is a resource (the process instance) that needs to be "used/updated" by each thread in turn, not all at once.
The reason I did not want to use your suggestion is that I think that this would block all traffic... In 60 seconds I may have 1,000 incoming events/threads, destined for 950 different process instances. In the vast majority of cases there is no contention and i could, in theory, process 950 process instances in parallel... with only 50 blocking.
The only solution that I can think of is to either use the jBpm lock facility OR to have an external locking process.
1) Using the jBpm lock facility
| long pid = 123;
| JbpmContext jC = jbpmConfiguration.createJbpmContext();
| try {
| ProcessInstance pI = jC.loadProcessInstanceForUpdate(pid);
| pI.getRootToken().lock(Thread.currentThread().toString());
| }
| finally {
| jC.close();
| }
| try {
| ProcessInstance pI = jC.loadProcessInstanceForUpdate(pid);
| pI.getRootToken().unlock(Thread.currentThread().toString());
| pI.signal();
| }
| finally {
| jC.close();
| }
|
The problem with this is it is pretty heavyweight (in terms of database updates done) and also I have to write a fair chunk of code to deal with threads that die without releasing their lock etc etc etc.
2) Implementing a a lock facility using the database, for example mysql SELECT GET_LOCK('lock1',10)
The problem with this is that I need to ensure that no thread attempts to acquire a process instance without first getting a lock.
Unfortunately the solution is multi node, so I am not able to do in memory locking easily.
I had hoped that jBpm might have a clever way of achieving this without me having to write any code. At an abstract level I believe that this problem is similar to a process instance reaching a task node whose task could be performed by multiple actors. Presumably in this case jBpm has some mechanism to prevent multiple actors fulfilling the task.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4196919#4196919
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4196919
15 years, 6 months
[JBoss jBPM] - Re: No auto-id for jbpm when running on Oracle
by janvandeklok
Ai Martin.... shame on me!!!
We have 2 hibernate.cfg.xml deployed in the jboss server: 1 that comes with the JBPM installation and 1 that was generated by SEAM for our application.
Since JBPM did create-drop the jbpm tables and that behaviour was NOT specified in the JBPM hibernate.cfg.xml but was specified in the SEAM hibernate.cfg.xml I thought hibernate was just using the SEAM configuration file. In the SEAM configuration file the proper oracle dialect was set, in the JBPM configuration file it was not!!
I changed the dialect and now the id generation work as does the hot deployment!!!
Thanks Martin I owe you one!!!!
What puzzles me however is that the JBPM hibernation reacts on the
<property name="hbm2ddl.auto">create-drop</property>
specified in the seam config file,
while in the jbpm config file the following property was set
<!-- Automatic schema creation (begin) -->
| <property name="hibernate.hbm2ddl.auto">none</property>
| <!-- Automatic schema creation (end) -->
I'm not a hibernate expert but these configuration files are using different keys for the same behaviour. That seems strange doesn't it?
Any way, Thanks for the help Martin.
Jan
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4196875#4196875
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4196875
15 years, 6 months
[JBoss jBPM] - Re: Problem with a decision node in a fork, join construct.
by mputz
To finish up on my tests from yesterday, removing the flush() in the Join re-introduced the failure on the direct link from fork to join:
| HSQLDB: 3.2.2: OK, 3.2.3: OK, 3.3.0: OK
| Oracle: 3.2.2: FAILED, 3.2.3: OK, 3.3.0: FAILED
| Postgres: 3.2.2: FAILED, 3.2.3: OK, 3.3.0: FAILED
|
Looks like our test suite is not covering this scenario correctly and needs to be enhanced.
@Jan, regarding the Oracle sequences, let's follow up on the other thread you've already opened.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4196849#4196849
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4196849
15 years, 6 months