[
https://jira.jboss.org/browse/JBPM-2886?page=com.atlassian.jira.plugin.sy...
]
Adam Laczynski commented on JBPM-2886:
--------------------------------------
You could define simple process definition for which the job will be created; the easiest
way is probably mark activity as async and add to that activity code which invoke
setRollbackOnly on the current transaction (e.g. in a listener on event start).
That use case requires jta implementation so you could simulate it in test environment
using one of the available standalone jta implementations like bitronix
(
http://docs.codehaus.org/display/BTM/Home) or atomikos (
http://www.atomikos.com/).
job is not released when the transaction is marked as rollback only
-------------------------------------------------------------------
Key: JBPM-2886
URL:
https://jira.jboss.org/browse/JBPM-2886
Project: jBPM
Issue Type: Bug
Security Level: Public(Everyone can see)
Components: Runtime Engine
Affects Versions: jBPM 4.3
Environment: - WebLogic 10.2.3
- jbpm 4.3
- Oracle 10g
Reporter: Adam Laczynski
Job is not released when the exception occurred during job execution and transaction is
marked as rollback only because synchronization cannot be registered in transaction
(according to javax.transaction.Transaction#registerSynchronization java doc: @exception
RollbackException Thrown to indicate that the transaction has been marked for rollback
only).
Following exception is thrown:
org.jbpm.api.JbpmException: couldn't register synchronization: test1
at
org.jbpm.pvm.internal.tx.JtaTransaction.registerSynchronization(JtaTransaction.java:78)
at
org.jbpm.pvm.internal.cmd.ExecuteJobCmd.handleJobExecutionException(ExecuteJobCmd.java:111)
at org.jbpm.pvm.internal.cmd.ExecuteJobCmd.execute(ExecuteJobCmd.java:92)
at org.jbpm.pvm.internal.cmd.ExecuteJobCmd.execute(ExecuteJobCmd.java:42)
at
org.jbpm.pvm.internal.svc.DefaultCommandService.execute(DefaultCommandService.java:42)
at
org.jbpm.pvm.internal.tx.JtaTransactionInterceptor.executeInNewTx(JtaTransactionInterceptor.java:87)
at
org.jbpm.pvm.internal.tx.JtaTransactionInterceptor.execute(JtaTransactionInterceptor.java:66)
at org.jbpm.pvm.internal.svc.RetryInterceptor.execute(RetryInterceptor.java:55)
at
org.jbpm.pvm.internal.tx.JtaRetryInterceptor.executeWithRetry(JtaRetryInterceptor.java:52)
at org.jbpm.pvm.internal.tx.JtaRetryInterceptor.execute(JtaRetryInterceptor.java:45)
at
org.jbpm.pvm.internal.svc.EnvironmentInterceptor.executeInNewEnvironment(EnvironmentInterceptor.java:53)
at
org.jbpm.pvm.internal.svc.EnvironmentInterceptor.execute(EnvironmentInterceptor.java:40)
at org.jbpm.pvm.internal.svc.SkipInterceptor.execute(SkipInterceptor.java:43)
at org.jbpm.pvm.internal.jobexecutor.JobParcel.run(JobParcel.java:48)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
at java.util.concurrent.FutureTask.run(FutureTask.java:138)
at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:619)
After that, job could be acquired again but only after the lockMillis (default 30
minutes).
IMO in such case the job has to be released because it delay job execution. To achieve it
JobExceptionHandler (with small modification) has to be register before invoking
job.execute(...) in org.jbpm.pvm.internal.cmd.ExecuteJobCmd:76. Exception could be passed
to the handler in the catch block.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://jira.jboss.org/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira