+++ This bug was initially created as a clone of Bug #1138412 +++

I have run a MortgageApplication process of official BPM Example in business-central. I chose the process parameter combination so the process enters data correction human task, activates swimlane, then goes to appraisal task out of swimlane and later to 'increase down payment task' back into the swimlane. However the third task produces the following error on start operation (claim is not necessary as the claim operation was done on the first data correction task in the same swimlane):

19:14:46,932 WARN [org.jbpm.services.task.audit.lifecycle.listeners.BAMTaskEventListener] (http-localhost.localdomain/127.0.0.1:8080-3) Something went wrong with the Task BAM Listener
19:14:46,933 WARN [org.jbpm.services.task.persistence.TaskTransactionInterceptor] (http-localhost.localdomain/127.0.0.1:8080-3) Could not commit session: java.lang.IllegalStateException: We cannot have more than one BAM Task Summary for the task id = 9
at org.jbpm.services.task.audit.lifecycle.listeners.BAMTaskEventListener.createOrUpdateTask(BAMTaskEventListener.java:258) [jbpm-human-task-audit-6.0.3-redhat-5.jar:6.0.3-redhat-5]

To reproduce:
1.) Setup BPMS 6.0.3.ER1 (http://dev138.mw.lab.eng.bos.redhat.com/candidate/bpms-6.0.3-ER1/) on EAP 6.1.2 (http://download.eng.brq.redhat.com/released/JBEAP-6/6.1.2/).
2.) Configure user guest with password guest, see hint below:
guest=b5d048a237bfd2874b6928e1f37ee15e
guest=admin,appraiser,broker,manager
3.) Setup official BPM example, you need to clone its repository to business-central:
http://git.app.eng.bos.redhat.com/git/jboss-bpm-example-app.git/tree/mortgage-demo-repo/src/main/resources/mortgage-demo
and also deploy its web service to EAP:
http://git.app.eng.bos.redhat.com/git/jboss-bpm-example-app.git/tree/mortgage-demo-ws
Or check the official BPM Example Application documentation.
4.) Start the BPMS.
5.) Run the remote test:
git clone git://git.app.eng.bos.redhat.com/jbossqe-process-flood.git
cd jbossqe-process-flood
git checkout bpms-6.0.x
mvn clean test -Dtest=MortgageApplicationBasicRestTest -Dmaven.test.skip=false

Expected behavior:
I do not understand where is the problem with BAM Task Summary, when this task is entered for the first time. Even if it would entered multiple times, this should not happen. The third task should be able to start without any problems.

My env:
BPMS 6.0.3.ER1
EAP 6.1.2
PostgreSQL 9.3.5

— Additional comment from Jiri Svitak on 2014-09-04 14:19:55 EDT —

The process model view of the flow I tried to achieve. The third task 'increase down payment' cannot be started and throws an exception.

— Additional comment from Kris Verlaenen on 2014-09-04 15:27:38 EDT —

Jiri, is it possible the database contained old information in the database (from previous executions)?

— Additional comment from Jiri Svitak on 2014-09-04 16:16:49 EDT —

I had this in mind. The steps above are reproducible on empty database.

— Additional comment from Jiri Svitak on 2014-09-04 16:24:41 EDT —

I see that I posted in the bug description wrong log lines with 'id = 9'. However that does not matter, the problem remains also on empty database and the attached server log has it right with 'id = 3', which corresponds to third task on empty database.

— Additional comment from Maciej Swiderski on 2014-09-16 08:04:22 EDT —

changed applied to ensure that current transaction entities are managed by the listeners that depend on JPA queries. JPA queries will not find current transaction entities due to default (enforced by jbpm/drools persistence logic) flush mode set to COMMIT.
That was preventing BAM listener to find the task that was first added and the auto claimed within same transaction and thus creating two entries for the same task.

jbpm
master:
https://github.com/droolsjbpm/jbpm/commit/d7065d5f4b509ac44dfd1bc3b91b058ecc66d308

— Additional comment from Jiri Svitak on 2014-11-19 06:59:55 EST —

Verified in BPMS 6.1.0.ER2.

— Additional comment from Jiri Svitak on 2014-11-19 07:12:26 EST —

Ryan, Rajesh,
this bug has been fixed on September 16th. But it was somehow missed by productization/engineering so it was not moved to ON_QA. My personal list of bugs awaiting verification is filtered to those, which have ON_QA status. I've noticed that I am QA contact of 28 MODIFIED bugs, so I guess that some of them were not properly changed to ON_QA and they are already fixed. Do we have a mistake in our processes?

— Additional comment from Ryan Zhang on 2014-11-20 04:25:34 EST —

Sorry, this should be my mistake.
I missed some issues due to some error in my bugzilla filter (I haven't include the Target release="---" ).
I have updated the bugzilla filter. Now
ON_QA list for ER2 are: https://url.corp.redhat.com/cf5b946

Btw there are some Bugzilla still in flag=...-6.1.0? status, since it 's early age in release cycle, I think they are all merged into the product branch. So I have include all of them with -6.1.0 flag into the ON_QA list.

Thanks Jiri for reminding me on the missing BZs.

(In reply to Jiri Svitak from comment #7)
> Ryan, Rajesh,
> this bug has been fixed on September 16th. But it was somehow missed by
> productization/engineering so it was not moved to ON_QA. My personal list of
> bugs awaiting verification is filtered to those, which have ON_QA status.
> I've noticed that I am QA contact of 28 MODIFIED bugs, so I guess that some
> of them were not properly changed to ON_QA and they are already fixed. Do we
> have a mistake in our processes?