JBossDeveloper

All right ... the timer is created in table .... and runs as it was supposed to run !!!! but the node is left and the timer still run .... i need to suspend the flow ... after the time has due, then goes to transition !!! and it is not happening !!!! what is wrong?

Hello,

Few questions regarding the following remark.

Or look at 3.1alpha. afaik, there is functionality to suspend and resume. It is alpha, so the code might not be finished.

Hi Raj,

you can do that with 3.0.2. All you need is a State node. That will return, stopping the process and leaving everything 'as is' until you trigger the processInstance / token by whatever means are applicable to your app.

Greetings

Hello Rainer,

Thanks for you reply. I know we have been over this before. I am trying to test with simple process definition and it does not work.

Here is my test process:

<?xml version="1.0" encoding="UTF-8"?>

<process-definition
 xmlns="http://jbpm.org/3/jpdl" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
 xsi:schemaLocation="http://jbpm.org/3/jpdl http://jbpm.org/xsd/jpdl-3.0.xsd"
 name="dbexample">
 <start-state name="start">
 <transition name="tr1" to="first"></transition>
 </start-state>
 <end-state name="end"></end-state>
 <state name="first">
 <transition name="tr1" to="second"></transition>
 <event type="node-enter">
 <action class="jpl.mipl.pgs.test.Testing">
 <leaveNode>false</leaveNode>
 <waitTimeBound>2000</waitTimeBound>
 </action>
 </event>
 </state>
 <state name="second">
 <transition name="tr1" to="end"></transition>
 <event type="node-enter">
 <action class="jpl.mipl.pgs.test.Testing" name="">
 <halt>true</halt>
 <leaveNode>false</leaveNode>
 <waitTimeBound>1000</waitTimeBound>
 </action>
 </event>
 </state>
</process-definition>

while (!executionContext.getToken().hasEnded())
 {
 ContextInstance ci = executionContext.getProcessInstance().getContextInstance();
 synchronized(ci)
 {
 if (ci.hasTransientVariable(jpl.mipl.pgs.test.Testing.HALT))
 {
 System.err.println("Halting token="+executionContext.getToken().getFullName()+
 " executed upto token="+executionContext.getToken().getName());
 return;
 }
 }
 //... code that persistes process instance
 executionContext.getToken().signal()
 //.....code that persists process instance
 ......

Exception in thread "main" org.hibernate.LazyInitializationException: failed to lazily initialize a collection of role: org.jbpm.graph.exe.Token.children, no session or session was closed
 at org.hibernate.collection.AbstractPersistentCollection.throwLazyInitializationException(AbstractPersistentCollection.java:358)
 at org.hibernate.collection.AbstractPersistentCollection.throwLazyInitializationExceptionIfNotConnected(AbstractPersistentCollection.java:350)
 at org.hibernate.collection.AbstractPersistentCollection.initialize(AbstractPersistentCollection.java:343)
 at org.hibernate.collection.AbstractPersistentCollection.read(AbstractPersistentCollection.java:86)
 at org.hibernate.collection.PersistentMap.entrySet(PersistentMap.java:206)
 at org.jbpm.graph.exe.Token.getActiveChildren(Token.java:366)
 at jpl.mipl.pgs.jbpm.JBPMExeEngine.execute(JBPMExeEngine.java:447)
 at jpl.mipl.pgs.jbpm.JBPMExeEngine.main(JBPMExeEngine.java:518)

Forgot to mention that the code to persist process instance starts a transaction, saves process instance and commits the transaction. So the signal is outside of transaction. I do not think this should matter as I have seen same problem when the signal is with in transaction.

Raj

Hi Raj,

first question: where do you get the executionContext from?

while (!executionContext.getToken().hasEnded())

Hello Rainer,

The execution context is created as follows

new ExecutionContext(processInstance.getRootToken());

Raj,

sorry if this sounds too intrusive, but what are you trying to accomplish?

Your approach seems extremely complicated to me and I have the impression that you are actually redundantly reimplementing behaviour jBPM already takes care of. token.signal() will traverse the processDefinition until it reaches a wait-state and only then return, which seems to be very similar to what you are trying to achieve. I don't have the time right now to trace it in detail, this is just a first impression.

Concerning your concurrency question: you will have to lock on the processInstance.

Greetings

Thanks Rainer,

I do understand that you are a busy man and many many thanks for you time.

The code in question implements parallel split. When process execution reaches the split node, threads are created for running each token separately (the main thread runs one of the token, the remanning n-1 are executed in new threads). Each thread (including the main) simply calls

token.signal(transitionName)

token.signal()

Hi Raj,

don't do it :-)

jBPM implements concurrent execution in a business process sense, NOT in a Java Thread sense. As you have to lock on processInstance anyway there is no real benefit in spawning two threads as one would always be waiting for the other so you might as well just use the jBPM Fork / Join nodes.

If your intention is real concurrency in the execution of long running task (find next prime number...) you would have to use a different approach. Send a JMS in an Action that triggers the task, return from the node (leaving it in a wait state) and let the executing MDB trigger the waiting token when it is finished. (Or check out the 3.1 async functionality, I haven't had a look at it yet.)

If you have two of these Actions in State nodes after your Fork you have real, Thread based concurrency.

If this sounds to complicated, check it out. Its not harder than what you are currently trying and it works :-)

Greetings