[jBPM Development] - Getting "Could not execute JDBC batch update" while running process in JBPM 5.1 with persistence
by uvijayreddy657
uvijayreddy657 [http://community.jboss.org/people/uvijayreddy657] created the discussion
"Getting "Could not execute JDBC batch update" while running process in JBPM 5.1 with persistence"
To view the discussion, visit: http://community.jboss.org/message/622394#622394
--------------------------------------------------------------
We have created all the required mapping tables as per the JPA entity classes. When we are running the process, it tries to insert the process instance data into the database and at that time we are facing below issue. Please see below for the error,
SLF4J: Failed to load class "org.slf4j.impl.StaticLoggerBinder".
SLF4J: Defaulting to no-operation (NOP) logger implementation
SLF4J: See http://www.slf4j.org/codes.html#StaticLoggerBinder http://www.slf4j.org/codes.html#StaticLoggerBinder for further details.
org.hibernate.ejb.EntityManagerImpl@fbf51d
1
In Human Task Handler.... :)
Completed
Hibernate: select hibernate_sequence.nextval from dual
Hibernate: select user_.id from OrganizationalEntity user_ where user_.id=?
Hibernate: select hibernate_sequence.nextval from dual
Hibernate: select hibernate_sequence.nextval from dual
Hibernate: select hibernate_sequence.nextval from dual
Hibernate: select hibernate_sequence.nextval from dual
Hibernate: insert into Task (allowedToDelegate, taskInitiator_id, priority, activationTime, actualOwner_id, createdBy_id, createdOn, documentAccessType, documentContentId, documentType, expirationTime, faultAccessType, faultContentId, faultName, faultType, outputAccessType, outputContentId, outputType, parentId, previousStatus, processInstanceId, skipable, status, workItemId, id) values (?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?)
Hibernate: insert into I18NText (language, text, id) values (?, ?, ?)
Hibernate: insert into I18NText (language, text, id) values (?, ?, ?)
Hibernate: insert into I18NText (language, text, id) values (?, ?, ?)
Hibernate: insert into Content (content, id) values (?, ?)
Hibernate: update Task set allowedToDelegate=?, taskInitiator_id=?, priority=?, activationTime=?, actualOwner_id=?, createdBy_id=?, createdOn=?, documentAccessType=?, documentContentId=?, documentType=?, expirationTime=?, faultAccessType=?, faultContentId=?, faultName=?, faultType=?, outputAccessType=?, outputContentId=?, outputType=?, parentId=?, previousStatus=?, processInstanceId=?, skipable=?, status=?, workItemId=? where id=?
javax.persistence.RollbackException: Error while committing the transaction
at org.hibernate.ejb.TransactionImpl.commit(TransactionImpl.java:93)
at org.jbpm.task.service.TaskServiceSession.doOperationInTransaction(TaskServiceSession.java:820)
at org.jbpm.task.service.TaskServiceSession.addTask(TaskServiceSession.java:134)
at org.jbpm.task.service.TaskServerHandler.messageReceived(TaskServerHandler.java:109)
at org.jbpm.task.service.mina.MinaTaskServerHandler.messageReceived(MinaTaskServerHandler.java:41)
at org.apache.mina.core.filterchain.DefaultIoFilterChain$TailFilter.messageReceived(DefaultIoFilterChain.java:713)
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:793)
at org.apache.mina.filter.codec.ProtocolCodecFilter$ProtocolDecoderOutputImpl.flush(ProtocolCodecFilter.java:375)
at org.apache.mina.filter.codec.ProtocolCodecFilter.messageReceived(ProtocolCodecFilter.java:229)
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:793)
at org.apache.mina.filter.logging.LoggingFilter.messageReceived(LoggingFilter.java:176)
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:793)
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:638)
at org.apache.mina.core.polling.AbstractPollingIoProcessor.process(AbstractPollingIoProcessor.java:598)
at org.apache.mina.core.polling.AbstractPollingIoProcessor.process(AbstractPollingIoProcessor.java:587)
at org.apache.mina.core.polling.AbstractPollingIoProcessor.access$400(AbstractPollingIoProcessor.java:61)
at org.apache.mina.core.polling.AbstractPollingIoProcessor$Processor.run(AbstractPollingIoProcessor.java:969)
at org.apache.mina.util.NamePreservingRunnable.run(NamePreservingRunnable.java:64)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:885)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:907)
at java.lang.Thread.run(Thread.java:619)
Caused by: javax.persistence.PersistenceException: org.hibernate.exception.ConstraintViolationException: Could not execute JDBC batch update
at org.hibernate.ejb.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1214)
at org.hibernate.ejb.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1147)
at org.hibernate.ejb.TransactionImpl.commit(TransactionImpl.java:81)
... 29 more
Caused by: org.hibernate.exception.ConstraintViolationException: Could not execute JDBC batch update
at org.hibernate.exception.SQLStateConverter.convert(SQLStateConverter.java:96)
at org.hibernate.exception.JDBCExceptionHelper.convert(JDBCExceptionHelper.java:66)
at org.hibernate.jdbc.AbstractBatcher.executeBatch(AbstractBatcher.java:275)
at org.hibernate.engine.ActionQueue.executeActions(ActionQueue.java:268)
at org.hibernate.engine.ActionQueue.executeActions(ActionQueue.java:185)
at org.hibernate.event.def.AbstractFlushingEventListener.performExecutions(AbstractFlushingEventListener.java:321)
at org.hibernate.event.def.DefaultFlushEventListener.onFlush(DefaultFlushEventListener.java:51)
at org.hibernate.impl.SessionImpl.flush(SessionImpl.java:1216)
at org.hibernate.impl.SessionImpl.managedFlush(SessionImpl.java:383)
at org.hibernate.transaction.JDBCTransaction.commit(JDBCTransaction.java:133)
at org.hibernate.ejb.TransactionImpl.commit(TransactionImpl.java:76)
... 29 more
Caused by: java.sql.BatchUpdateException: ORA-02291: integrity constraint (SDS_OWNR.FK27A9A56CE1EF3A) violated - parent key not found
at oracle.jdbc.driver.DatabaseError.throwBatchUpdateException(DatabaseError.java:343)
at oracle.jdbc.driver.OraclePreparedStatement.executeBatch(OraclePreparedStatement.java:10720)
at org.hibernate.jdbc.BatchingBatcher.doExecuteBatch(BatchingBatcher.java:70)
at org.hibernate.jdbc.AbstractBatcher.executeBatch(AbstractBatcher.java:268)
... 37 more
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/622394#622394]
Start a new discussion in jBPM Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
12 years, 12 months
[JBoss AS7 Development] - Re: Weld-OSGi integration in AS7
by Kevin Pollet
Kevin Pollet [http://community.jboss.org/people/kevinpollet] created the discussion
"Re: Weld-OSGi integration in AS7"
To view the discussion, visit: http://community.jboss.org/message/605472#605472
--------------------------------------------------------------
> Thoughts?
Hi all,
I just want to give you my thinking and Mathieu's thinking about the use of the OSGiService qualifier. First of all, we agree with you that it's possible to get rid of the OSGiService qualifier (if a service is not found in CDI, it's possible to look at the OSGi service registry).
I thought a lot about this and one interrogation comes to my mind. How differentiate the case of a missing CDI binding and the case of a local implementation for a service? The default behavior of CDI is to throw an exception specifying that there is no binding for this injection target but in this case, a proxy waiting for an hypothetical OSGi service will be injected (and obviously will fail at runtime). IMHO, doing this will break the default CDI programming model. I mean that the user applicition will start without any problem in our case but in the default CDI programming model an exception will be thrown. We think that the user have to specify where he wants to use OSGi (so the user will knows where to deal with OSGi dynamism).
On the other hand, as you say in your above comments, this feature has to be enabled by the user. In this case he could be aware of this behavior, but we think it's too much changes for the CDI programming model.
WDYT?
Kevin & Mathieu
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/605472#605472]
Start a new discussion in JBoss AS7 Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
13 years
[JBoss AS7 Development] - Custom resource adapter and MDB
by Takayoshi Kimura
Takayoshi Kimura [http://community.jboss.org/people/tkimura] created the discussion
"Custom resource adapter and MDB"
To view the discussion, visit: http://community.jboss.org/message/620023#620023
--------------------------------------------------------------
Hi,
I'm using AS7 head (7.1.0.Alpha1-SNAPSHOT) and I've created a basic resource adapter for twitter and an MDB. The files are twitter-ra.rar and twittermdb.jar. My code is hosted at GitHub https://github.com/nekop/twitter-resource-adapter https://github.com/nekop/twitter-resource-adapter .
There are 2 issues in EJBUtilities.
1. When I put those files in the standalone/deployment directory the MDB deployment failed with the following exception:
java.lang.IllegalStateException: Not found RA registered as twitter-ra
EJBUtilities tries to find a corresponding rar in the following way:
for (String id : getMdr().getResourceAdapters()) {
if (getMdr().getRoot(id).getName().indexOf(resourceAdapterName) != -1) {
but this doesn't work because the File#getName() method of the deployment root File returns just "content". It's not a rar name.
2. @ResourceAdapter("twitter-ra.rar") doesn't work but @ResourceAdapter("twitter-ra") works
Because the resource adapter id is "twitter-ra". I thought we support both with and without ".rar".
What's the design behind the current logic? Could it be a problem if we replaced the code with the following?
String resourceAdapterId =
resourceAdapterName.endsWith(".rar") ?
resourceAdapterName.substring(0, resourceAdapterName.length() - ".rar".length()) :
resourceAdapterName;
if (!raFound && getMdr().getResourceAdapter(resourceAdapterId) != null) {
ResourceAdapter ra = getMdr().getResourceAdapter(resourceAdapterId).getResourceadapter();
if (ra instanceof ResourceAdapter1516
&& ((ResourceAdapter1516) ra).getInboundResourceadapter() != null) {
String className = ((ResourceAdapter1516) ra).getResourceadapterClass();
if (className.lastIndexOf(".") != -1)
packageName = className.substring(0, className.lastIndexOf("."));
else
packageName = "";
raFound = true;
}
}
Thanks,
Takayoshi
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/620023#620023]
Start a new discussion in JBoss AS7 Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
13 years
[JBoss Transactions Development] - Remoting Transport Transaction Inflow Design Discussion
by David Lloyd
David Lloyd [http://community.jboss.org/people/dmlloyd] created the discussion
"Remoting Transport Transaction Inflow Design Discussion"
To view the discussion, visit: http://community.jboss.org/message/621318#621318
--------------------------------------------------------------
This is a starting point for discussion for the support of transaction control in conjunction with Remoting-based invocation. All the items in this document are subject to discussion and revision! There will be a design conference call among the concerned parties in which the details of these points will be worked out; afterwards, a revised version of this document will be made available for any further discussion.
Problem:
It is required that in order to maintain the appropriate level of compatibility with previous releases, the Remoting EJB transport must support a means by which the transactional state of the server can be controlled. Historically, this has been accomplished using a remote view of UserTransaction. This is simple to implement in a "thin" client, and is described in the first solution section. However, implementing this in the context of a server communicating with another server is difficult. Thus another approach is proposed below for this scenario, which has been described as "JTA inflow" or "JCA-style inflow".
Note that these two solutions are in addition to two other existing options: JTS and simply not supporting transactions.
0. Definitions
0.1. Client invocation context - the context associated with a thread on the client side of an invocation, which in turn relates to a specific Remoting connection providing its transport.
1. Solution description (Remoting JTA client):
This solution applies to standalone, "thin" clients without a local transaction manager.
1.1. Client API and invocation
1.1.1. The client will control transactions on the server using a variation of the UserTransaction interface, which may be accessed via JNDI or other mechanisms in place of a TM-provided UserTransaction implementation.
1.1.2. Any initiated transaction will be associated with the client thread and client invocation context, and assigned a simple ID which is associated with remote invocations made by that thread during its duration.
1.1.3. The implementation of this interface will use a simple Remoting-based protocol to forward the method invocations to the server along with the ID of the transaction in question. (A connection may be shared across multiple client threads, thus it is possible for one connection to control many transactions.)
1.1.4. Upon invocation, the client will attach the ID associated with the current thread's transaction to the invocation as a "transaction ID attachment" as it is executed.
1.2. Server side
1.2.1. Incoming transaction control commands cause transactions to be begun, committed, and rolled back.
1.2.2. Begun transactions are suspended and the resultant Transaction object is associated with the connection, along with the ID of the transaction.
1.2.3. Incoming invocations with a transaction ID attachment are associated with the suspended Transaction, and the Transaction is resumed for the duration of the method invocation.
1.2.4. If the client session is lost or terminated, any outstanding Transactions are rolled back.
1.3. Unaddressed issues
1.3.1. Transaction timeout control
2. Solution description (Remoting JTA inflow):
This solution applies to servers with a local transaction manager.
2.1. Invocation, client side
2.1.1. Upon invocation, the client will locate (via the local TransactionManager) the current active Transaction and enlist into it an XAResource instance corresponding to the client invocation context.
2.1.2. The Xid and any pertinent ancillary information regarding the current transaction which were provided to the XAResource will be attached to the invocation as a "transaction inflow attachment" as it is executed.
2.1.2.1. Xid propagation should rely on a byte representation, not a serialized object, in order to support multiple marshalling schemes.
2.1.3. Transaction control methods invoked upon the XAResource will be forwarded as commands over the Remoting channel to the server.
2.2. Invocation, server side
2.2.1. Incoming invocations which have a transaction inflow attachment will trigger the use of an interceptor which utilizes the XATerminator (or equivalent) interface to import the transaction for the duration of the invocation execution.
2.2.2. Incoming XAResource commands will be translated into invocations on the local XATerminator (or equivalent) to carry out transaction completion.
2.2.3. If the client session is lost or terminated, any open transactions are rolled back; any prepared but incomplete transactions have to be recovered manually.
2.3. Recovery
2.3.1. The client is expected to use "JTA top-down recovery", which will treat the participating server(s) as additional local resources to recover. The client is always treated as the originator of the transaction.
2.3.2. The client invocation context must expose a means to acquire its XAResource in order to facilitate local recovery.
2.4. Unaddressed Issues
2.4.1. Transaction timeout control
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/621318#621318]
Start a new discussion in JBoss Transactions Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
13 years