Red Hat Bugzilla – Bug 1022910
Could not initialize a collection in PostgreSQL caused by Large Objects may not be used in auto-commit mode
Last modified: 2016-09-20 01:05:11 EDT
Created attachment 815708 [details]
Description of problem:
When I want to get a task instance info via JMS API, I won't receive the response because there is an exception on the server side.
GenericJDBCException: could not initialize a collection: [org.jbpm.services.task.impl.model.TaskImpl.names#10]
Caused by: org.postgresql.util.PSQLException: Large Objects may not be used in auto-commit mode.
There was the same issue BZ 971376 with JBPM engine itself which was considered to not be a bug and might help you to find the problem.
How to reproduce:
1. Install BPMS 6.0.0.ER4 with EAP 6.1.0 and configure it to use PostgreSQL 9.2
2. Create simple BPMN process defition containing a single human task
3. Start a process instance of previous definition
4. Get task instance info via JMS API, use new JaxbCommandsRequest(new GetTaskCommand(taskId)); to send
5. See the exceptions in server log
if BZ 971376 wasn't a bug, this shoudn't be a bug.
I'm assigning Marco to the task because it's realted with the JMS endpoint. But it really seems that it is the same as the BZ 971376
but this issue is on the server side, there must be some code which is not performed within a transaction if I well understand the cause.
This is a human-task issue: the problem is that the human-task returns an entity -- that is using the underlying hibernate (collection) classes. Because hibernate uses lazy initialization, some of these collections have *not yet* been initialized (filled with their values) at the time that the entity has been returned by the TaskService to the JMS api.
Unfortunately, the human-task engine doesn't include logic to deal with this situation because it treats the entity (TaskImpl) that it returns as an API object. The human-task architecture basically incorrectly assumes that once it's retrieved an entity and executed its internal business logic, it can then close the transaction: this is incorrect because the entity objects themselves are returned to the users and thus are susceptible to transaction and entity manager state.
In BRMS 5.x, we could deal with this within human-task code itself because the external interfaces (mina, hornetq) were part of the human-task component. In BZ 852044 (see below), we ended up extending the scope of transactions in HT to around all serialization actions.
(This same issue was also present in BRMS 5.x for which we ended up having to put transactions around a number of query operations in order to serialize the return object before ending the transactions, see https://bugzilla.redhat.com/show_bug.cgi?id=852044 )
Unfortunately, human-task no longer has an external interface, which means that I now have to fix a problem in the *JMS api* that is a result of the problematic architecture in human-task!
I've already fixed this problem once! And I'm fixing it again?!? Something doesn't make sense here..
I have to return this bug due to the same issue with REST API. I noticed that the issue appears only when I want to get task instance info. It's this method taskId what I call remotely https://github.com/droolsjbpm/droolsjbpm-integration/blob/master/kie-remote/kie-services-remote/src/main/java/org/kie/services/remote/rest/TaskResource.java#L168
The above commits were the last touches: a lot of the ground work was actually done by Maciej's partial rewrite of human-task, which made fixing this much, much, much easier.
Maciej's rewrite can be found here:
Verified in BPMS 6.0.0.CR1