Bug 771745

Summary:	TaskServiceSession.getContent(long contentId) bombs in JTA environment with PostgreSQL
Product:	[JBoss] JBoss Enterprise BRMS Platform 5	Reporter:	Jeffrey Bride <jbride2001>
Component:	jBPM 5	Assignee:	Kris Verlaenen <kverlaen>
Status:	VERIFIED ---	QA Contact:	Jiri Locker <jlocker>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	BRMS 5.3.0.GA	CC:	lpetrovi
Target Milestone:	ER6	Keywords:	Reopened, TestBlocker
Target Release:	BRMS 5.3.0.GA
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2012-01-17 15:44:11 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:

Description Jeffrey Bride 2012-01-04 20:05:51 UTC

using stock PostgreSQL from RHEL5.5 or Fedora 14/15/16, the TaskServiceSession.getContent() method throws the "Large Objects may not be used in auto-commit mode" exception.

Please see the getContent() method found in the following link for a suggested fix :

https://github.com/jbride/jbpm/blob/5.2.x-gbd/jbpm-human-task/src/main/java/org/jbpm/task/service/TaskServiceSession.java

Comment 1 Zuzana Krejčová 2012-03-28 14:16:21 UTC

This is a bug, happens with jBPM 5 in BRMS 5.3.0 ER5. Using this version with PostgrSQL 8.2, 8.3, 8.4 results in:

WARN  [org.hibernate.util.JDBCExceptionReporter] (NioProcessor-4) SQL Error: 0, SQLState: 25P01
ERROR [org.hibernate.util.JDBCExceptionReporter] (NioProcessor-4) Large Objects may not be used in auto-commit mode.
INFO  [org.hibernate.event.def.DefaultLoadEventListener] (NioProcessor-4) Error performing load command
org.hibernate.exception.GenericJDBCException: could not load an entity: [org.jbpm.task.Content#60]
	at org.hibernate.exception.SQLStateConverter.handledNonSpecificException(SQLStateConverter.java:126)
	at org.hibernate.exception.SQLStateConverter.convert(SQLStateConverter.java:114)
	at org.hibernate.exception.JDBCExceptionHelper.convert(JDBCExceptionHelper.java:66)
	at org.hibernate.loader.Loader.loadEntity(Loader.java:2086)
	at org.hibernate.loader.entity.AbstractEntityLoader.load(AbstractEntityLoader.java:71)
	at org.hibernate.loader.entity.AbstractEntityLoader.load(AbstractEntityLoader.java:65)
	at org.hibernate.persister.entity.AbstractEntityPersister.load(AbstractEntityPersister.java:3062)
	at org.hibernate.event.def.DefaultLoadEventListener.loadFromDatasource(DefaultLoadEventListener.java:434)
	at org.hibernate.event.def.DefaultLoadEventListener.doLoad(DefaultLoadEventListener.java:415)
	at org.hibernate.event.def.DefaultLoadEventListener.load(DefaultLoadEventListener.java:165)
	at org.hibernate.event.def.DefaultLoadEventListener.proxyOrLoad(DefaultLoadEventListener.java:223)
	at org.hibernate.event.def.DefaultLoadEventListener.onLoad(DefaultLoadEventListener.java:126)
	at org.hibernate.impl.SessionImpl.fireLoad(SessionImpl.java:908)
	at org.hibernate.impl.SessionImpl.get(SessionImpl.java:845)
	at org.hibernate.impl.SessionImpl.get(SessionImpl.java:838)
	at org.hibernate.ejb.AbstractEntityManagerImpl.find(AbstractEntityManagerImpl.java:182)
	at org.jbpm.task.service.TaskServiceSession.getEntity(TaskServiceSession.java:910)
	at org.jbpm.task.service.TaskServiceSession.getContent(TaskServiceSession.java:567)
	at org.jbpm.task.service.TaskServerHandler.messageReceived(TaskServerHandler.java:195)
	at org.jbpm.task.service.mina.MinaTaskServerHandler.messageReceived(MinaTaskServerHandler.java:41)
	at org.apache.mina.core.filterchain.DefaultIoFilterChain$TailFilter.messageReceived(DefaultIoFilterChain.java:716)
	at org.apache.mina.core.filterchain.DefaultIoFilterChain.callNextMessageReceived(DefaultIoFilterChain.java:434)
	at org.apache.mina.core.filterchain.DefaultIoFilterChain.access$1200(DefaultIoFilterChain.java:46)
	at org.apache.mina.core.filterchain.DefaultIoFilterChain$EntryImpl$1.messageReceived(DefaultIoFilterChain.java:796)
	at org.apache.mina.filter.codec.ProtocolCodecFilter$ProtocolDecoderOutputImpl.flush(ProtocolCodecFilter.java:427)
	at org.apache.mina.filter.codec.ProtocolCodecFilter.messageReceived(ProtocolCodecFilter.java:245)
	at org.apache.mina.core.filterchain.DefaultIoFilterChain.callNextMessageReceived(DefaultIoFilterChain.java:434)
	at org.apache.mina.core.filterchain.DefaultIoFilterChain.access$1200(DefaultIoFilterChain.java:46)
	at org.apache.mina.core.filterchain.DefaultIoFilterChain$EntryImpl$1.messageReceived(DefaultIoFilterChain.java:796)
	at org.apache.mina.filter.logging.LoggingFilter.messageReceived(LoggingFilter.java:177)
	at org.apache.mina.core.filterchain.DefaultIoFilterChain.callNextMessageReceived(DefaultIoFilterChain.java:434)
	at org.apache.mina.core.filterchain.DefaultIoFilterChain.access$1200(DefaultIoFilterChain.java:46)
	at org.apache.mina.core.filterchain.DefaultIoFilterChain$EntryImpl$1.messageReceived(DefaultIoFilterChain.java:796)
	at org.apache.mina.core.filterchain.IoFilterAdapter.messageReceived(IoFilterAdapter.java:119)
	at org.apache.mina.core.filterchain.DefaultIoFilterChain.callNextMessageReceived(DefaultIoFilterChain.java:434)
	at org.apache.mina.core.filterchain.DefaultIoFilterChain.fireMessageReceived(DefaultIoFilterChain.java:426)
	at org.apache.mina.core.polling.AbstractPollingIoProcessor.read(AbstractPollingIoProcessor.java:692)
	at org.apache.mina.core.polling.AbstractPollingIoProcessor.process(AbstractPollingIoProcessor.java:645)
	at org.apache.mina.core.polling.AbstractPollingIoProcessor.process(AbstractPollingIoProcessor.java:634)
	at org.apache.mina.core.polling.AbstractPollingIoProcessor.access$400(AbstractPollingIoProcessor.java:66)
	at org.apache.mina.core.polling.AbstractPollingIoProcessor$Processor.run(AbstractPollingIoProcessor.java:1078)
	at org.apache.mina.util.NamePreservingRunnable.run(NamePreservingRunnable.java:64)
	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:662)
Caused by: org.postgresql.util.PSQLException: Large Objects may not be used in auto-commit mode.
	at org.postgresql.largeobject.LargeObjectManager.open(LargeObjectManager.java:200)
	at org.postgresql.largeobject.LargeObjectManager.open(LargeObjectManager.java:172)
	at org.postgresql.jdbc2.AbstractJdbc2BlobClob.<init>(AbstractJdbc2BlobClob.java:47)
	at org.postgresql.jdbc2.AbstractJdbc2Blob.<init>(AbstractJdbc2Blob.java:21)
	at org.postgresql.jdbc3.AbstractJdbc3Blob.<init>(AbstractJdbc3Blob.java:19)
	at org.postgresql.jdbc4.AbstractJdbc4Blob.<init>(AbstractJdbc4Blob.java:20)
	at org.postgresql.jdbc4.Jdbc4Blob.<init>(Jdbc4Blob.java:20)
	at org.postgresql.jdbc4.Jdbc4ResultSet.getBlob(Jdbc4ResultSet.java:52)
	at org.postgresql.jdbc2.AbstractJdbc2ResultSet.getBlob(AbstractJdbc2ResultSet.java:335)
	at org.jboss.resource.adapter.jdbc.WrappedResultSet.getBlob(WrappedResultSet.java:386)
	at org.hibernate.type.ByteArrayBlobType.get(ByteArrayBlobType.java:85)
	at org.hibernate.type.AbstractLobType.nullSafeGet(AbstractLobType.java:46)
	at org.hibernate.type.AbstractType.hydrate(AbstractType.java:105)
	at org.hibernate.persister.entity.AbstractEntityPersister.hydrate(AbstractEntityPersister.java:2114)
	at org.hibernate.loader.Loader.loadFromResultSet(Loader.java:1589)
	at org.hibernate.loader.Loader.instanceNotYetLoaded(Loader.java:1517)
	at org.hibernate.loader.Loader.getRow(Loader.java:1415)
	at org.hibernate.loader.Loader.getRowFromResultSet(Loader.java:643)
	at org.hibernate.loader.Loader.doQuery(Loader.java:867)
	at org.hibernate.loader.Loader.doQueryAndInitializeNonLazyCollections(Loader.java:298)
	at org.hibernate.loader.Loader.doQueryAndInitializeNonLazyCollections(Loader.java:280)
	at org.hibernate.loader.Loader.loadEntity(Loader.java:2072)
	... 41 more

Changing the auto-commit mode might help, sure, it still is a bug that the Task Service should handle.

Comment 5 Marco Rietveld 2012-04-04 11:16:44 UTC

Hi Zuzanna, 

This happened because the Content object (which contains a LOB), was being retrieved without a tx. "Large Objects" in postgresql require that because of the 'Large Object Facility'. 

Fixed in both master and 5.2.x.

Comment 6 Ryan Zhang 2012-04-23 07:38:05 UTC

Update status to ON_QA. Please verify them against ER6.

Comment 8 Jiri Locker 2012-06-01 10:50:02 UTC

The issue no longer occurs. Verified in ER8.