AbstractBpm5Action is doing some handler registration for *each* process instance start and service callback: .... ksession.getWorkItemManager().registerWorkItemHandler("JBossESB", esbhandler); ksession.getWorkItemManager().registerWorkItemHandler("ESBAction", actionhandler); ksession.getWorkItemManager().registerWorkItemHandler("Human Task", khandler); 'khandler' in particular is an instance of CommandBasedHornetQWSHumanTaskHandler by default. So when the user goes to close a task, all those handlers fire (JPA trips up, too): 012-08-22 12:32:06,006 INFO [STDOUT] (Thread-32) Notification of completed task 132 2012-08-22 12:32:06,017 INFO [STDOUT] (Thread-34) Notification of completed task 132 2012-08-22 12:32:06,025 INFO [STDOUT] (Thread-35) Notification of completed task 132 2012-08-22 12:32:06,033 INFO [STDOUT] (Thread-36) Notification of completed task 132 2012-08-22 12:32:06,042 INFO [STDOUT] (Thread-37) Notification of completed task 132 2012-08-22 12:32:06,049 INFO [STDOUT] (Thread-37) Notification of completed task 132 2012-08-22 12:32:06,056 INFO [STDOUT] (Thread-38) Notification of completed task 132 2012-08-22 12:32:06,063 INFO [STDOUT] (Thread-39) Notification of completed task 132 2012-08-22 12:32:06,069 INFO [STDOUT] (Thread-40) Notification of completed task 132 2012-08-22 12:32:06,076 INFO [STDOUT] (Thread-41) Notification of completed task 132 2012-08-22 12:32:06,082 INFO [STDOUT] (Thread-41) Notification of completed task 132 2012-08-22 12:32:05,985 INFO [STDOUT] (Thread-31) Notification of completed task 132 2012-08-22 12:32:05,998 ERROR [org.hibernate.event.def.AbstractFlushingEventListener] (Thread-31) Could not synchronize database state with session org.hibernate.StaleObjectStateException: Row was updated or deleted by another transaction (or unsaved-value mapping was incorrect): [org.jbpm.persistence.processinstance.ProcessInstanceInfo#44] at org.hibernate.persister.entity.AbstractEntityPersister.check(AbstractEntityPersister.java:1782) ....... at org.jbpm.task.service.hornetq.CommandBasedHornetQWSHumanTaskHandler$GetCompletedTaskResponseHandler.execute(CommandBasedHornetQWSHumanTaskHandler.java:273)
Why is this marked as private? What is the status of this bugreport? Thanks
Changed permissions to mkae public. (Sorry, it looks like I had marked it private even though no customer-specific information is here.) I've tentatively added this bug to Roll up patch SOA_5.3_2_2012. We'll know more about ETA as other work progresses. Thanks, Rick
Tom Cunningham <tcunning> updated the status of jira JBESB-3862 to Resolved
Tom Cunningham <tcunning> made a comment on jira JBESB-3862 Only register the handlers once - we had been registering handlers every time a process instance was started.
Tom Cunningham <tcunning> updated the status of jira JBESB-3862 to Closed
This BZ is for 5.3.1. There is a 5.3_2 Roll up BZ that matches it 876280.
Created attachment 649687 [details] Server Log
Created attachment 649688 [details] Reproducer
The race condition between handlers still occurs. See attached server.log. The stack in the server log can be easily reproduced using the following steps. 1) deploy the attached esb application 2) invoke it a few times {code} Message esbMessage = MessageFactory.getInstance().getMessage(); esbMessage.getBody().add("Empty"); new ServiceInvoker("FirstServiceESB", "StartListener").deliverSync(esbMessage, 5000L); {code} 3) go to the console, log in as krisv:krisv and attempt to complete one of the tasks.
*** Bug 881925 has been marked as a duplicate of this bug. ***
Tom Cunningham <tcunning> updated the status of jira JBESB-3862 to Reopened
*** Bug 904952 has been marked as a duplicate of this bug. ***
This product has been discontinued or is no longer tracked in Red Hat Bugzilla.