Bug 1022910 - Could not initialize a collection in PostgreSQL caused by Large Objects may not be used in auto-commit mode
Could not initialize a collection in PostgreSQL caused by Large Objects may n...
Product: JBoss BPMS Platform 6
Classification: JBoss
Component: Business Central (Show other bugs)
Unspecified Unspecified
high Severity high
: CR1
: 6.0.0
Assigned To: Marco Rietveld
Ivo Bek
Depends On:
  Show dependency treegraph
Reported: 2013-10-24 05:16 EDT by Ivo Bek
Modified: 2016-09-20 01:05 EDT (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2014-08-06 16:07:56 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
server log (19.57 KB, text/x-log)
2013-10-24 05:16 EDT, Ivo Bek
no flags Details

  None (edit)
Description Ivo Bek 2013-10-24 05:16:12 EDT
Created attachment 815708 [details]
server log

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
Comment 1 Mauricio Salatino 2013-10-24 05:18:56 EDT
Hi Ivo, 
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
Comment 2 Ivo Bek 2013-10-24 05:30:19 EDT
Hi Mauricio,

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.
Comment 3 Marco Rietveld 2013-10-31 15:50:53 EDT
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..
Comment 5 Ivo Bek 2013-12-09 05:05:13 EST
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
Comment 7 Marco Rietveld 2013-12-19 17:27:06 EST



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: 
6.0.x:  https://github.com/droolsjbpm/jbpm/commit/cc430e3c
master: https://github.com/droolsjbpm/jbpm/commit/6ecf49b7
Comment 9 Ivo Bek 2014-01-22 07:01:36 EST
Verified in BPMS 6.0.0.CR1

Note You need to log in before you can comment on or make changes to this bug.