[jBPM] - AS 7.1.2, JBPM 5.3 persistence : Getting Large Objects may not be used in auto-commit mode exception
by Vimal Kansal
Vimal Kansal [https://community.jboss.org/people/vimalkansal] created the discussion
"AS 7.1.2, JBPM 5.3 persistence : Getting Large Objects may not be used in auto-commit mode exception"
To view the discussion, visit: https://community.jboss.org/message/738264#738264
--------------------------------------------------------------
Hi,
I am using jBPM 5.3 as embedded engine in JEE6 web application and have configured the persistence. The application deploys and I can see jbpm tables getting created in the database. My sample code for executing the workflow is :
//@Stateless
@Named("workFlow")
public class WorkflowManager {
@Inject @Knowledge //@Knowledge is the user defined CDI qualifier.
private KnowledgeBase kbase;
@Inject
@JBPMPeristenceFactory // my own CDI Qualifier, for typesafe Injection of EntityManagerFactory
private EntityManagerFactory emf;
public void startWorkFlow(){
try {
TransactionManager tm = null;
tm = (TransactionManager)new InitialContext().lookup( "java:jboss/TransactionManager" ); //lookup the transaction manager
Environment env = KnowledgeBaseFactory.newEnvironment();
env.set( EnvironmentName.ENTITY_MANAGER_FACTORY,emf); //set the entity manager factory
env.set( EnvironmentName.TRANSACTION_MANAGER, tm); //set the transaction manager
ksession.startProcess("demo.jbpmDemo");
} catch (Exception e) {
// TODO Auto-generated catch block
e.printStackTrace();
}
}
}
When the startWorkFlow method is invoked, I get the following exception :
I am not sure why it is being executed in auto commit mode. Also I am not sure whether it is PostGreSQL issue. Can somebody please help.
=============================================================================================
... 70 more
Caused by: javax.persistence.PersistenceException: org.hibernate.exception.GenericJDBCException: Large Objects may not be used in auto-commit mode.
at org.hibernate.ejb.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1365) [hibernate-entitymanager-4.1.3.ER1-redhat-1.jar:4.1.3.ER1-redhat-1]
at org.hibernate.ejb.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1293) [hibernate-entitymanager-4.1.3.ER1-redhat-1.jar:4.1.3.ER1-redhat-1]
at org.hibernate.ejb.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1299) [hibernate-entitymanager-4.1.3.ER1-redhat-1.jar:4.1.3.ER1-redhat-1]
at org.hibernate.ejb.AbstractEntityManagerImpl$CallbackExceptionMapperImpl.mapManagedFlushFailure(AbstractEntityManagerImpl.java:1485) [hibernate-entitymanager-4.1.3.ER1-redhat-1.jar:4.1.3.ER1-redhat-1]
at org.hibernate.engine.transaction.synchronization.internal.SynchronizationCallbackCoordinatorImpl.beforeCompletion(SynchronizationCallbackCoordinatorImpl.java:109) [hibernate-core-4.1.3.ER1-redhat-1.jar:4.1.3.ER1-redhat-1]
at org.hibernate.engine.transaction.synchronization.internal.RegisteredSynchronization.beforeCompletion(RegisteredSynchronization.java:53) [hibernate-core-4.1.3.ER1-redhat-1.jar:4.1.3.ER1-redhat-1]
at com.arjuna.ats.internal.jta.resources.arjunacore.SynchronizationImple.beforeCompletion(SynchronizationImple.java:76)
at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.beforeCompletion(TwoPhaseCoordinator.java:273)
at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.end(TwoPhaseCoordinator.java:93)
at com.arjuna.ats.arjuna.AtomicAction.commit(AtomicAction.java:164)
at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.commitAndDisassociate(TransactionImple.java:1165)
... 73 more
Caused by: org.hibernate.exception.GenericJDBCException: Large Objects may not be used in auto-commit mode.
at org.hibernate.exception.internal.StandardSQLExceptionConverter.convert(StandardSQLExceptionConverter.java:54) [hibernate-core-4.1.3.ER1-redhat-1.jar:4.1.3.ER1-redhat-1]
at org.hibernate.engine.jdbc.spi.SqlExceptionHelper.convert(SqlExceptionHelper.java:125) [hibernate-core-4.1.3.ER1-redhat-1.jar:4.1.3.ER1-redhat-1]
at org.hibernate.engine.jdbc.spi.SqlExceptionHelper.convert(SqlExceptionHelper.java:110) [hibernate-core-4.1.3.ER1-redhat-1.jar:4.1.3.ER1-redhat-1]
at org.hibernate.engine.jdbc.internal.proxy.AbstractStatementProxyHandler.continueInvocation(AbstractStatementProxyHandler.java:129) [hibernate-core-4.1.3.ER1-redhat-1.jar:4.1.3.ER1-redhat-1]
at org.hibernate.engine.jdbc.internal.proxy.AbstractProxyHandler.invoke(AbstractProxyHandler.java:81) [hibernate-core-4.1.3.ER1-redhat-1.jar:4.1.3.ER1-redhat-1]
at $Proxy67.setBlob(Unknown Source) at org.hibernate.type.descriptor.sql.BlobTypeDescriptor$3$1.doBind(BlobTypeDescriptor.java:91) [hibernate-core-4.1.3.ER1-redhat-1.jar:4.1.3.ER1-redhat-1]
at org.hibernate.type.descriptor.sql.BasicBinder.bind(BasicBinder.java:92) [hibernate-core-4.1.3.ER1-redhat-1.jar:4.1.3.ER1-redhat-1]
at org.hibernate.type.AbstractStandardBasicType.nullSafeSet(AbstractStandardBasicType.java:305) [hibernate-core-4.1.3.ER1-redhat-1.jar:4.1.3.ER1-redhat-1]
at org.hibernate.type.AbstractStandardBasicType.nullSafeSet(AbstractStandardBasicType.java:300) [hibernate-core-4.1.3.ER1-redhat-1.jar:4.1.3.ER1-redhat-1]
at org.hibernate.type.AbstractSingleColumnStandardBasicType.nullSafeSet(AbstractSingleColumnStandardBasicType.java:57) [hibernate-core-4.1.3.ER1-redhat-1.jar:4.1.3.ER1-redhat-1]
at org.hibernate.persister.entity.AbstractEntityPersister.dehydrate(AbstractEntityPersister.java:2598) [hibernate-core-4.1.3.ER1-redhat-1.jar:4.1.3.ER1-redhat-1]
at org.hibernate.persister.entity.AbstractEntityPersister.insert(AbstractEntityPersister.java:2852) [hibernate-core-4.1.3.ER1-redhat-1.jar:4.1.3.ER1-redhat-1]
at org.hibernate.persister.entity.AbstractEntityPersister.insert(AbstractEntityPersister.java:3296) [hibernate-core-4.1.3.ER1-redhat-1.jar:4.1.3.ER1-redhat-1]
at org.hibernate.action.internal.EntityInsertAction.execute(EntityInsertAction.java:88) [hibernate-core-4.1.3.ER1-redhat-1.jar:4.1.3.ER1-redhat-1]
at org.hibernate.engine.spi.ActionQueue.execute(ActionQueue.java:362) [hibernate-core-4.1.3.ER1-redhat-1.jar:4.1.3.ER1-redhat-1]
at org.hibernate.engine.spi.ActionQueue.executeActions(ActionQueue.java:354) [hibernate-core-4.1.3.ER1-redhat-1.jar:4.1.3.ER1-redhat-1]
at org.hibernate.engine.spi.ActionQueue.executeActions(ActionQueue.java:275) [hibernate-core-4.1.3.ER1-redhat-1.jar:4.1.3.ER1-redhat-1]
at org.hibernate.event.internal.AbstractFlushingEventListener.performExecutions(AbstractFlushingEventListener.java:326) [hibernate-core-4.1.3.ER1-redhat-1.jar:4.1.3.ER1-redhat-1]
at org.hibernate.event.internal.DefaultFlushEventListener.onFlush(DefaultFlushEventListener.java:52) [hibernate-core-4.1.3.ER1-redhat-1.jar:4.1.3.ER1-redhat-1]
at org.hibernate.internal.SessionImpl.flush(SessionImpl.java:1181) [hibernate-core-4.1.3.ER1-redhat-1.jar:4.1.3.ER1-redhat-1]
at org.hibernate.internal.SessionImpl.managedFlush(SessionImpl.java:379) [hibernate-core-4.1.3.ER1-redhat-1.jar:4.1.3.ER1-redhat-1]
at org.hibernate.engine.transaction.synchronization.internal.SynchronizationCallbackCoordinatorImpl.beforeCompletion(SynchronizationCallbackCoordinatorImpl.java:104) [hibernate-core-4.1.3.ER1-redhat-1.jar:4.1.3.ER1-redhat-1]
... 79 more
Caused by: org.postgresql.util.PSQLException: Large Objects may not be used in auto-commit mode.
at org.postgresql.largeobject.LargeObjectManager.createLO(LargeObjectManager.java:241)
at org.postgresql.largeobject.LargeObjectManager.createLO(LargeObjectManager.java:228)
at org.postgresql.jdbc2.AbstractJdbc2Statement.setBlob(AbstractJdbc2Statement.java:2901)
at org.jboss.jca.adapters.jdbc.WrappedPreparedStatement.setBlob(WrappedPreparedStatement.java:1073)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.6.0_31]
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) [rt.jar:1.6.0_31]
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) [rt.jar:1.6.0_31]
at java.lang.reflect.Method.invoke(Method.java:597) [rt.jar:1.6.0_31]
at org.hibernate.engine.jdbc.internal.proxy.AbstractStatementProxyHandler.continueInvocation(AbstractStatementProxyHandler.java:122) [hibernate-core-4.1.3.ER1-redhat-1.jar:4.1.3.ER1-redhat-1]
... 98 more
===================================================================================================================================================
--------------------------------------------------------------
Reply to this message by going to Community
[https://community.jboss.org/message/738264#738264]
Start a new discussion in jBPM at Community
[https://community.jboss.org/choose-container!input.jspa?contentType=1&con...]
13 years, 9 months
[jBPM] - jbpm 5.3 - GenericCommandBasedWSHumanTaskHandler and LocalTaskService, how to use it?
by Pedro Gonçalves
Pedro Gonçalves [https://community.jboss.org/people/pgoncalves] created the discussion
"jbpm 5.3 - GenericCommandBasedWSHumanTaskHandler and LocalTaskService, how to use it?"
To view the discussion, visit: https://community.jboss.org/message/744818#744818
--------------------------------------------------------------
I was using the deprecated class SyncWSHumanTaskHandler like this:
SyncWSHumanTaskHandler handler = new SyncWSHumanTaskHandler(localTaskService, kSession);
handler.setLocal(true)
kSession.getWorkItemManager().registerWorkItemHandler("Human Task", handler);
handler.connect();
But since I'm using persistence and in the docs says to use the CommandBasedWSHumanTaskHandler I want to change it, but I can't set the client as the localTaskService.
GenericCommandBasedWSHumanTaskHandler handler = new GenericCommandBasedWSHumanTaskHandler(kSession);
kSession.getWorkItemManager().registerWorkItemHandler("Human Task", handler);
When executing, gives this error:
java.lang.IllegalStateException: You must provide a client connector for the Client using the setClient() method
at org.jbpm.process.workitem.wsht.GenericCommandBasedWSHumanTaskHandler.connect(GenericCommandBasedWSHumanTaskHandler.java:122)
at org.jbpm.process.workitem.wsht.GenericCommandBasedWSHumanTaskHandler.executeWorkItem(GenericCommandBasedWSHumanTaskHandler.java:137)
Is it possible to use the GenericCommandBasedWSHumanTaskHandler with the LocalTaskService?
Or,
How can I use it without using HornetQ, Mina or JMS?
Thanks
--------------------------------------------------------------
Reply to this message by going to Community
[https://community.jboss.org/message/744818#744818]
Start a new discussion in jBPM at Community
[https://community.jboss.org/choose-container!input.jspa?contentType=1&con...]
13 years, 9 months
[jBPM] - jbpm 5.3.final postgres issue
by Miloud Haimoune
Miloud Haimoune [https://community.jboss.org/people/milhaim] created the discussion
"jbpm 5.3.final postgres issue"
To view the discussion, visit: https://community.jboss.org/message/740678#740678
--------------------------------------------------------------
Hi all,
I'm migrating the code of my application to use jbpm latest release (5.3.final). but I'm facing this exception when I create a new process instance :
13:01:13,688 WARN [JDBCExceptionReporter] SQL Error: 0, SQLState: 42804
13:01:13,688 ERROR [JDBCExceptionReporter] ERROR: column "processinstancebytearray" is of type oid but expression is of type bytea
Hint: You will need to rewrite or cast the expression.
Position: 149.
I found a post wich advises to use a recent version of hibernate 3.6.final. but I m using jboss 5.1 which provides hibenate 3.1 and I don't think it's very wise hibernate (used by another application).
the some code was working fine with JBPM 5.2.final
if you have any solution ??
many thanks
--------------------------------------------------------------
Reply to this message by going to Community
[https://community.jboss.org/message/740678#740678]
Start a new discussion in jBPM at Community
[https://community.jboss.org/choose-container!input.jspa?contentType=1&con...]
13 years, 9 months
[Javassist] - Matching and replacing a sequence of bytecodes/instructions
by susanin
susanin [https://community.jboss.org/people/susanin] created the discussion
"Matching and replacing a sequence of bytecodes/instructions"
To view the discussion, visit: https://community.jboss.org/message/745206#745206
--------------------------------------------------------------
Hi,
I have the following problem to solve:
I need to detect assignments to a specific field, where the right-hand side is also of a specific form, e.g. it is the same field (or the field of the same specific type) of another object:
obj1.fieldX = obj2.fieldX
The reason for looking for such a pattern is an (peephole) optimization of the code that I generate using Javassist. Currently, I have my basic transformation working (using *javassist.expr.FieldAccess*), but it treats such assignments as two independent operations:
read from fieldX of obj2
write into fieldX of obj1
and I cannot see that they are used in combination and cannot optimize such a typical use-case. As a result, the generated code is rather inefficient at run-time and is about 2-3 times slower, because both transformations done independently result in prodicing a lot of heap-allocated intermediary objects of complex types. Those objects are generated as a result of a read and some of their fields are initialized from obj2.fieldX. Then write does the opposite action, i.e. copies some of those fields of a newly allocated object into a target object, i.e. into ob1.fieldX. And then the intermediary object is not used any more. My wish is to directly copy some information from obj2.fieldX into obj1.fieldX, without generating all those useless intermediary objects on heap.
Therefore I have questions:
1) Is it in principle possible using Javassist to detect something like this and to replace the whole expression by a new code or transform it?
I've seen that BCEL has something like this for matching sequences of byte-codes - it has code matching using regular expressions, like "NOP+(ILOAD|ALOAD)*" (http://commons.apache.org/bcel/manual.html, section 3.3.7). May be Javassist also has it in a certain form?
2) May be FieldAccess allows access to additional information using $_, $0 or $1, so that one can try to match a pattern against a the target (i.e. $_) of read or value argument of a write and perform a dedicated action if it is detected?
3) May be there are other ways rather than code matching at the bytecode level to achieve my goal?
Thanks,
Leo
--------------------------------------------------------------
Reply to this message by going to Community
[https://community.jboss.org/message/745206#745206]
Start a new discussion in Javassist at Community
[https://community.jboss.org/choose-container!input.jspa?contentType=1&con...]
13 years, 9 months