Hello,
could you explain me a bit bpel execution regarding BpelRuntimeContext?
I saw a following happened:
09:59:25,185 | INFO | pool-4-thread-4 | BpelRuntimeContextImpl |
.engine.BpelRuntimeContextImpl 160 | BpelRuntimeContextImpl created
for instance 20598 24589427
09:59:25,269 | INFO | pool-4-thread-7 | BpelRuntimeContextImpl |
.engine.BpelRuntimeContextImpl 160 | BpelRuntimeContextImpl created
for instance 20598 1821816
09:59:25,628 | INFO | pool-4-thread-4 | BpelRuntimeContextImpl |
.engine.BpelRuntimeContextImpl 843 | BpelRuntimeContextImpl setting
execution state on instance 20598 24589427
09:59:25,781 | INFO | pool-4-thread-7 | BpelRuntimeContextImpl |
.engine.BpelRuntimeContextImpl 843 | BpelRuntimeContextImpl setting
execution state on instance 20598 1821816
The numbers at the end (24589427 and 1821816) are hash ids for
BpelRuntimeContextImpl.
It happened after executing concurrently two jobs INVOKE_RESPONSE for
invoke1 and invoke3. A bpel process was like this:
<flow>
<sequence>
<invoke1/>
<invoke2/>
</sequence>
<sequence>
<invoke3/>
<invoke4/>
</sequence>
</flow>
My question is whether such execution should be made synchronized in
ODE? Here setting execution state happened concurrently in
pool-4-thread-4 and pool-4-thread-7.
I used transaction isolation level READ_COMMITTED (a default one). In
this scenario, I had two jobs concurrently, successfully committed and
no critical section was used.
Both transactions saw committed data, so READ_COMMITTED was held.
It lead to storing incorrect execution state for process instance in
DB, since one INVOKE_RESPONSE job work was lost due to overwritten
data.
What transaction isolation level is correct for ODE? And what should I
do to correct this scenario? Do you have any clues?
I had an error in Oracle:
09:59:27,383 | ERROR | pool-4-thread-7 | JacobVPU |
b.vpu.JacobVPU$JacobThreadImpl 463 | Method "run" in class
"org.apache.ode.bpel.engine.BpelRuntimeContextImpl$6" threw an
unexpected excep
tion.
java.lang.IllegalArgumentException: No such channel; id=225
at
org.apache.ode.jacob.vpu.ExecutionQueueImpl.findChannelFrame(ExecutionQueueImpl.java:205)
at
org.apache.ode.jacob.vpu.ExecutionQueueImpl.consumeExport(ExecutionQueueImpl.java:232)
at
org.apache.ode.jacob.vpu.JacobVPU$JacobThreadImpl.importChannel(JacobVPU.java:369)
at org.apache.ode.jacob.JacobObject.importChannel(JacobObject.java:47)
at
org.apache.ode.bpel.engine.BpelRuntimeContextImpl$6.run(BpelRuntimeContextImpl.java:967)
at sun.reflect.GeneratedMethodAccessor120.invoke(Unknown Source)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at
org.apache.ode.jacob.vpu.JacobVPU$JacobThreadImpl.run(JacobVPU.java:451)
at org.apache.ode.jacob.vpu.JacobVPU.execute(JacobVPU.java:139)
at
org.apache.ode.bpel.engine.BpelRuntimeContextImpl.execute(BpelRuntimeContextImpl.java:839)
at
org.apache.ode.bpel.engine.BpelProcess.handleWorkEvent(BpelProcess.java:418)
at
org.apache.ode.bpel.engine.BpelEngineImpl.onScheduledJob(BpelEngineImpl.java:424)
at
org.apache.ode.bpel.engine.BpelServerImpl.onScheduledJob(BpelServerImpl.java:377)
at
org.apache.ode.scheduler.simple.SimpleScheduler$4$1.call(SimpleScheduler.java:386)
at
org.apache.ode.scheduler.simple.SimpleScheduler$4$1.call(SimpleScheduler.java:380)
at
org.apache.ode.scheduler.simple.SimpleScheduler.execTransaction(SimpleScheduler.java:208)
at
org.apache.ode.scheduler.simple.SimpleScheduler$4.call(SimpleScheduler.java:379)
at
org.apache.ode.scheduler.simple.SimpleScheduler$4.call(SimpleScheduler.java:376)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:269)
at java.util.concurrent.FutureTask.run(FutureTask.java:123)
at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:650)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:675)
at java.lang.Thread.run(Thread.java:595)
And in Derby, there was a dead lock.
Regards,
--
Rafał Rusin
www.mimuw.edu.pl/~rrusin
