XA transactions timeout with essentials / eclipselink
I'm attempting to do an XA (container managed) tranasction throught a series of remote EJB calls. Database is 11g
When the JPA provider is toplink-essentials or EclipseLink the the end of the 2PC hangs. Eventually it times out with an "Error allocating connection". Monitoring of the connection pool shows there are lots of free
However this work with Hibernate 3.
How do I use XA transactions on 11g with toplink/eclipselink.
Thanks for looking at this. I can send a full code sample if needed. Sorry for the full stack traces.
The Setup
There are three parts to my application.
+1) an ejb which writes "Nice Weather" to the database+
+2) an ejb which calls the nice weather remotely then returns "Hello World"+
+3) a junit test which connects to the ORB of the "HelloWorld" which in turn calls the "NiceWeather"+
Using Toplink-essentials and ojdbc6.jar
The database user has all grants/admin/privileges. Assigned by clicking on the Grant ALL and Admin All in the SQL developer edit user.
In NiceWeather ejb the persistence.xml looks like
+<?xml version="1.0" encoding="UTF-8"?>+
+<persistence version="1.0" xmlns="http://java.sun.com/xml/ns/persistence" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://java.sun.com/xml/ns/persistence http://java.sun.com/xml/ns/persistence/persistence_1_0.xsd">+
+<persistence-unit name="NiceWeatherPU" transaction-type="JTA">+
+<provider>oracle.toplink.essentials.PersistenceProvider</provider>+
+<jta-data-source>jdbc/helloRemoteEJB</jta-data-source>+
+<exclude-unlisted-classes>false</exclude-unlisted-classes>+
+<properties>+
+<property name="toplink.ddl-generation" value="drop-and-create-tables"/>+
+<property name="toplink.logging.logger" value="JavaLogger"/>+
+<property name="toplink.logging.level" value="FINEST"/>+
+</properties>+
+</persistence-unit>+
+</persistence>+
the Connection pool backing jdbc/helloRemoteEJB looks like
Name: Oracle-11g-XA
Datasource Classname: javax.sql.XADataSource
Resource Type: javax.sql.DataSource javax.sql.XADataSource
User: example
password: example
url: jdbc:oracle:thin:@localhost:1521:orcl
Passing Case
When run with both components (HelloWorld-ejb and NiceWeather-ejb) deployed on the same Application Server instance (Glassfish v2ur2) the tests pass and everything is happy
the log messages for the NiceWeather-ejb are:
begin deploying Persistence Unit NiceWeatherPU; state Predeployed; factoryCount 1
property=toplink.target-server; value=oracle.toplink.essentials.platform.server.sunas.SunAS9ServerPlatform
property=toplink.logging.logger; value=JavaLogger; translated value=oracle.toplink.essentials.logging.JavaLog
property=toplink.logging.level; value=FINEST; translated value=FINEST
property=toplink.logging.level; value=FINEST; translated value=FINEST
TopLink, version: Oracle TopLink Essentials - 2.0.1 (Build b04-fcs (04/11/2008))
Server: unknown
DBPlatform: oracle.toplink.essentials.platform.database.InformixPlatform, RegularExpression: (?i)informix.*.
DBPlatform: oracle.toplink.essentials.platform.database.PointBasePlatform, RegularExpression: (?i)pointbase.*.
DBPlatform: oracle.toplink.essentials.platform.database.DB2Platform, RegularExpression: (?i).*db2.*.
DBPlatform: oracle.toplink.essentials.platform.database.SQLServerPlatform, RegularExpression: (?i)microsoft.*.
DBPlatform: oracle.toplink.essentials.platform.database.PostgreSQLPlatform, RegularExpression: (?i)postgresql.*.
DBPlatform: oracle.toplink.essentials.platform.database.SybasePlatform, RegularExpression: (?i)(sybase.*)
DBPlatform: oracle.toplink.essentials.platform.database.JavaDBPlatform, RegularExpression: (?i).*derby.
DBPlatform: oracle.toplink.essentials.platform.database.oracle.OraclePlatform, RegularExpression: (?i)oracle.*.
Detected Vendor platform: oracle.toplink.essentials.platform.database.oracle.OraclePlatform
connecting(DatabaseLogin(
platform=>DatabasePlatform
user name=> ""
connector=>JNDIConnector datasource name=>null
+))+
Connected: jdbc:oracle:thin:@localhost:1521:orcl
User: DD
Database: Oracle Version: Oracle Database 11g Enterprise Edition Release 11.1.0.6.0 - Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options
Driver: Oracle JDBC driver Version: 11.1.0.7.0-Production
connecting(DatabaseLogin(
platform=>OraclePlatform
user name=> ""
connector=>JNDIConnector datasource name=>null
+))+
Connected: jdbc:oracle:thin:@localhost:1521:orcl
User: DD
Database: Oracle Version: Oracle Database 11g Enterprise Edition Release 11.1.0.6.0 - Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options
Driver: Oracle JDBC driver Version: 11.1.0.7.0-Production
sequencing connected, state is Preallocation_Transaction_NoAccessor_State
sequence SEQ_GEN: preallocation size 50
file:/C:/Apps/1-Projects/other/RemoteEJB/NiceWeather/build/jar/-NiceWeatherPU login successful
end deploying Persistence Unit NiceWeatherPU; state Deployed; factoryCount 1
client acquired
TX binding to tx mgr, status=STATUS_ACTIVE
Execute query DoesExistQuery()
+PERSIST operation called on: example.remoteejb.entity.Weather[id=null].+
TX beginTransaction, status=STATUS_ACTIVE
Execute query DataModifyQuery()
reconnecting to external connection pool
UPDATE SEQUENCE SET SEQ_COUNT = SEQ_COUNT ? WHERE SEQ_NAME = ?+
bind => [50, SEQ_GEN]
Execute query ValueReadQuery()
SELECT SEQ_COUNT FROM SEQUENCE WHERE SEQ_NAME = ?
+bind => [SEQ_GEN]+
local sequencing preallocation for SEQ_GEN: objects: 50 , first: 2, last: 51
+assign sequence to the object (2 -> example.remoteejb.entity.Weather[id=null])+
TX beforeCompletion callback, status=STATUS_ACTIVE
begin unit of work commit
TX beginTransaction, status=STATUS_ACTIVE
+Execute query InsertObjectQuery(example.remoteejb.entity.Weather[id=2])+
INSERT INTO WEATHER (ID, MESSAGE) VALUES (?, ?)
bind => [2, Nice Weather1228420595934]
TX afterCompletion callback, status=COMMITTED
local sequencing preallocation is copied to preallocation after transaction commit
end unit of work commit
Failed Case
When the HelloWorld-ejb is deployed to a different Application server instance the log messages for the NiceWeather-ejb are:
client acquired
TX binding to tx mgr, status=STATUS_ACTIVE
Execute query DoesExistQuery()
+PERSIST operation called on: example.remoteejb.entity.Weather[id=null].+
+assign sequence to the object (3 -> example.remoteejb.entity.Weather[id=null])+
TX beforeCompletion callback, status=STATUS_ACTIVE
begin unit of work commit
TX beginTransaction, status=STATUS_ACTIVE
+Execute query InsertObjectQuery(example.remoteejb.entity.Weather[id=3])+
reconnecting to external connection pool
A potential connection leak detected for connection pool DD-XA-ojdbc6-11.1.0.7.0. The stack trace of the thread is provided below :
com.sun.enterprise.resource.AbstractResourcePool.setResourceStateToBusy(AbstractResourcePool.java:301)
com.sun.enterprise.resource.AbstractResourcePool.getResourceFromPool(AbstractResourcePool.java:778)
com.sun.enterprise.resource.AbstractResourcePool.getUnenlistedResource(AbstractResourcePool.java:652)
com.sun.enterprise.resource.AssocWithThreadResourcePool.getUnenlistedResource(AssocWithThreadResourcePool.java:136)
com.sun.enterprise.resource.AbstractResourcePool.internalGetResource(AbstractResourcePool.java:594)
com.sun.enterprise.resource.AbstractResourcePool.getResource(AbstractResourcePool.java:443)
com.sun.enterprise.resource.PoolManagerImpl.getResourceFromPool(PoolManagerImpl.java:248)
com.sun.enterprise.resource.PoolManagerImpl.getResource(PoolManagerImpl.java:176)
com.sun.enterprise.connectors.ConnectionManagerImpl.internalGetConnection(ConnectionManagerImpl.java:337)
com.sun.enterprise.connectors.ConnectionManagerImpl.allocateConnection(ConnectionManagerImpl.java:189)
com.sun.enterprise.connectors.ConnectionManagerImpl.allocateConnection(ConnectionManagerImpl.java:165)
com.sun.enterprise.connectors.ConnectionManagerImpl.allocateConnection(ConnectionManagerImpl.java:158)
com.sun.gjc.spi.base.DataSource.getConnection(DataSource.java:108)
oracle.toplink.essentials.jndi.JNDIConnector.connect(JNDIConnector.java:145)
oracle.toplink.essentials.sessions.DatasourceLogin.connectToDatasource(DatasourceLogin.java:184)
oracle.toplink.essentials.internal.databaseaccess.DatasourceAccessor.connect(DatasourceAccessor.java:233)
oracle.toplink.essentials.internal.databaseaccess.DatabaseAccessor.connect(DatabaseAccessor.java:242)
oracle.toplink.essentials.internal.databaseaccess.DatasourceAccessor.reconnect(DatasourceAccessor.java:436)
oracle.toplink.essentials.internal.databaseaccess.DatabaseAccessor.reconnect(DatabaseAccessor.java:1177)
oracle.toplink.essentials.internal.databaseaccess.DatasourceAccessor.incrementCallCount(DatasourceAccessor.java:220)
oracle.toplink.essentials.internal.databaseaccess.DatabaseAccessor.basicExecuteCall(DatabaseAccessor.java:479)
oracle.toplink.essentials.internal.databaseaccess.DatabaseAccessor.executeCall(DatabaseAccessor.java:452)
oracle.toplink.essentials.internal.sessions.AbstractSession.executeCall(AbstractSession.java:690)
oracle.toplink.essentials.internal.queryframework.DatasourceCallQueryMechanism.executeCall(DatasourceCallQueryMechanism.java:228)
oracle.toplink.essentials.internal.queryframework.DatasourceCallQueryMechanism.executeCall(DatasourceCallQueryMechanism.java:214)
oracle.toplink.essentials.internal.queryframework.DatasourceCallQueryMechanism.insertObject(DatasourceCallQueryMechanism.java:346)
oracle.toplink.essentials.internal.queryframework.StatementQueryMechanism.insertObject(StatementQueryMechanism.java:191)
oracle.toplink.essentials.internal.queryframework.StatementQueryMechanism.insertObject(StatementQueryMechanism.java:205)
oracle.toplink.essentials.internal.queryframework.DatabaseQueryMechanism.insertObjectForWrite(DatabaseQueryMechanism.java:564)
oracle.toplink.essentials.queryframework.InsertObjectQuery.executeCommit(InsertObjectQuery.java:89)
oracle.toplink.essentials.internal.queryframework.DatabaseQueryMechanism.performUserDefinedWrite(DatabaseQueryMechanism.java:750)
oracle.toplink.essentials.internal.queryframework.DatabaseQueryMechanism.performUserDefinedInsert(DatabaseQueryMechanism.java:714)
oracle.toplink.essentials.internal.queryframework.DatabaseQueryMechanism.insertObjectForWriteWithChangeSet(DatabaseQueryMechanism.java:602)
oracle.toplink.essentials.queryframework.WriteObjectQuery.executeCommitWithChangeSet(WriteObjectQuery.java:162)
oracle.toplink.essentials.internal.queryframework.DatabaseQueryMechanism.executeWriteWithChangeSet(DatabaseQueryMechanism.java:390)
oracle.toplink.essentials.queryframework.WriteObjectQuery.executeDatabaseQuery(WriteObjectQuery.java:109)
oracle.toplink.essentials.queryframework.DatabaseQuery.execute(DatabaseQuery.java:628)
oracle.toplink.essentials.queryframework.DatabaseQuery.executeInUnitOfWork(DatabaseQuery.java:555)
oracle.toplink.essentials.queryframework.ObjectLevelModifyQuery.executeInUnitOfWorkObjectLevelModifyQuery(ObjectLevelModifyQuery.java:138)
oracle.toplink.essentials.queryframework.ObjectLevelModifyQuery.executeInUnitOfWork(ObjectLevelModifyQuery.java:110)
oracle.toplink.essentials.internal.sessions.UnitOfWorkImpl.internalExecuteQuery(UnitOfWorkImpl.java:2233)
oracle.toplink.essentials.internal.sessions.AbstractSession.executeQuery(AbstractSession.java:952)
oracle.toplink.essentials.internal.sessions.AbstractSession.executeQuery(AbstractSession.java:909)
oracle.toplink.essentials.internal.sessions.CommitManager.commitNewObjectsForClassWithChangeSet(CommitManager.java:269)
oracle.toplink.essentials.internal.sessions.CommitManager.commitAllObjectsWithChangeSet(CommitManager.java:190)
oracle.toplink.essentials.internal.sessions.AbstractSession.writeAllObjectsWithChangeSet(AbstractSession.java:2657)
oracle.toplink.essentials.internal.sessions.UnitOfWorkImpl.commitToDatabase(UnitOfWorkImpl.java:1044)
oracle.toplink.essentials.internal.ejb.cmp3.base.RepeatableWriteUnitOfWork.commitToDatabase(RepeatableWriteUnitOfWork.java:403)
oracle.toplink.essentials.internal.sessions.UnitOfWorkImpl.commitToDatabaseWithChangeSet(UnitOfWorkImpl.java:1126)
oracle.toplink.essentials.internal.sessions.UnitOfWorkImpl.issueSQLbeforeCompletion(UnitOfWorkImpl.java:2443)
oracle.toplink.essentials.internal.ejb.cmp3.base.RepeatableWriteUnitOfWork.issueSQLbeforeCompletion(RepeatableWriteUnitOfWork.java:202)
oracle.toplink.essentials.transaction.AbstractSynchronizationListener.beforeCompletion(AbstractSynchronizationListener.java:131)
oracle.toplink.essentials.transaction.JTASynchronizationListener.beforeCompletion(JTASynchronizationListener.java:91)
com.sun.jts.jta.SynchronizationImpl.before_completion(SynchronizationImpl.java:99)
com.sun.jts.CosTransactions.RegisteredSyncs.distributeBefore(RegisteredSyncs.java:158)
com.sun.jts.CosTransactions.TopCoordinator.beforeCompletion(TopCoordinator.java:2548)
com.sun.jts.CosTransactions.CoordinatorSynchronizationImpl.before_completion(CoordinatorSynchronizationImpl.java:181)
org.omg.CosTransactions.SynchronizationPOA._invoke(SynchronizationPOA.java:39)
com.sun.corba.ee.impl.protocol.CorbaServerRequestDispatcherImpl.dispatchToServant(CorbaServerRequestDispatcherImpl.java:687)
com.sun.corba.ee.impl.protocol.CorbaServerRequestDispatcherImpl.dispatch(CorbaServerRequestDispatcherImpl.java:227)
com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.handleRequestRequest(CorbaMessageMediatorImpl.java:1846)
com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.handleRequest(CorbaMessageMediatorImpl.java:1706)
com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.handleInput(CorbaMessageMediatorImpl.java:1088)
com.sun.corba.ee.impl.protocol.giopmsgheaders.RequestMessage_1_2.callback(RequestMessage_1_2.java:223)
com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.handleRequest(CorbaMessageMediatorImpl.java:806)
com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.dispatch(CorbaMessageMediatorImpl.java:563)
com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.doWork(CorbaMessageMediatorImpl.java:2567)
com.sun.corba.ee.impl.orbutil.threadpool.ThreadPoolImpl$WorkerThread.run(ThreadPoolImpl.java:555)
Monitoring Statistics :
PoolCounters:
maxNumConnUsed = 1
minNumConnUsed = 0
currNumConnUsed = -5
maxNumConnFree = = 14
minNumConnFree = 0
currNumConnFree = 13
numConnCreated = 26
numConnDestroyed = 18
numConnFailedValidation = 0
numConnTimedOut = 0
numConnAcquired = 10
numConnReleased = 9
currConnectionRequestWait = 0
minConnectionRequestWait = 0
maxConnectionRequestWait = 2172
totalConnectionRequestWait = 2172
numConnSuccessfullyMatched = 10
numConnNotSuccessfullyMatched = 0
numPotentialConnLeak = 0
_<It hangs at this point, eventually the transaction times out>_
IOP00410219: (COMM_FAILURE) Communications timeout waiting for response. Exceeded 1,800,000 milliseconds"
org.omg.CORBA.COMM_FAILURE: vmcid: SUN minor code: 219 completed: Maybe
at com.sun.corba.ee.impl.logging.ORBUtilSystemException.communicationsTimeoutWaitingForResponse(ORBUtilSystemException.java:3180)
at com.sun.corba.ee.impl.logging.ORBUtilSystemException.communicationsTimeoutWaitingForResponse(ORBUtilSystemException.java:3195)
at com.sun.corba.ee.impl.transport.CorbaResponseWaitingRoomImpl.waitForResponse(CorbaResponseWaitingRoomImpl.java:198)
at com.sun.corba.ee.impl.transport.SocketOrChannelConnectionImpl.waitForResponse(SocketOrChannelConnectionImpl.java:1196)
at com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.handleRequest(CorbaMessageMediatorImpl.java:806)
at com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.dispatch(CorbaMessageMediatorImpl.java:563)
at com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.doWork(CorbaMessageMediatorImpl.java:2567)
at com.sun.corba.ee.impl.orbutil.threadpool.ThreadPoolImpl$WorkerThread.run(ThreadPoolImpl.java:555)
RAR5027:Unexpected exception in resource pooling
org.omg.CORBA.COMM_FAILURE: vmcid: SUN minor code: 219 completed: Maybe
at com.sun.corba.ee.impl.logging.ORBUtilSystemException.communicationsTimeoutWaitingForResponse(ORBUtilSystemException.java:3180)
at com.sun.corba.ee.impl.logging.ORBUtilSystemException.communicationsTimeoutWaitingForResponse(ORBUtilSystemException.java:3195)
at com.sun.corba.ee.impl.transport.CorbaResponseWaitingRoomImpl.waitForResponse(CorbaResponseWaitingRoomImpl.java:198)
at com.sun.corba.ee.impl.transport.SocketOrChannelConnectionImpl.waitForResponse(SocketOrChannelConnectionImpl.java:1196)
at com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.waitForResponse(CorbaMessageMediatorImpl.java:291)
at com.sun.corba.ee.impl.protocol.CorbaClientRequestDispatcherImpl.marshalingComplete1(CorbaClientRequestDispatcherImpl.java:389)
at com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.dispatch(CorbaMessageMediatorImpl.java:563)
at com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.doWork(CorbaMessageMediatorImpl.java:2567)
at com.sun.corba.ee.impl.orbutil.threadpool.ThreadPoolImpl$WorkerThread.run(ThreadPoolImpl.java:555)
poolmgr.err_enlisting_res_in_getconn
+RAR5117 : Failed to obtain/create connection from connection pool [ DD-XA-ojdbc6-11.1.0.7.0 ]. Reason : org.omg.CORBA.COMM_FAILURE: vmcid: SUN minor code: 219 completed: Maybe+
+RAR5114 : Error allocating connection : [Error in allocating a connection. Cause: org.omg.CORBA.COMM_FAILURE: vmcid: SUN minor code: 219 completed: Maybe]+
Local Exception Stack:
+Exception [TOPLINK-4002] (Oracle TopLink Essentials - 2.0.1 (Build b04-fcs (04/11/2008))): oracle.toplink.essentials.exceptions.DatabaseException+
Internal Exception: java.sql.SQLException: Error in allocating a connection. Cause: org.omg.CORBA.COMM_FAILURE: vmcid: SUN minor code: 219 completed: Maybe
Error Code: 0
Call: SQLCall(INSERT INTO WEATHER (ID, MESSAGE) VALUES (?, ?))
+Query: InsertObjectQuery(example.remoteejb.entity.Weather[id=3])+
at oracle.toplink.essentials.exceptions.DatabaseException.sqlException(DatabaseException.java:305)
at oracle.toplink.essentials.jndi.JNDIConnector.connect(JNDIConnector.java:150)
at oracle.toplink.essentials.sessions.DatasourceLogin.connectToDatasource(DatasourceLogin.java:184)
at com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.dispatch(CorbaMessageMediatorImpl.java:563)
at com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.doWork(CorbaMessageMediatorImpl.java:2567)
at com.sun.corba.ee.impl.orbutil.threadpool.ThreadPoolImpl$WorkerThread.run(ThreadPoolImpl.java:555)
Caused by: java.sql.SQLException: Error in allocating a connection. Cause: org.omg.CORBA.COMM_FAILURE: vmcid: SUN minor code: 219 completed: Maybe
at com.sun.gjc.spi.base.DataSource.getConnection(DataSource.java:115)
at oracle.toplink.essentials.jndi.JNDIConnector.connect(JNDIConnector.java:145)
+... 54 more+
Local Exception Stack:
+Exception [TOPLINK-4002] (Oracle TopLink Essentials - 2.0.1 (Build b04-fcs (04/11/2008))): oracle.toplink.essentials.exceptions.DatabaseException+
Internal Exception: java.sql.SQLException: Error in allocating a connection. Cause: org.omg.CORBA.COMM_FAILURE: vmcid: SUN minor code: 219 completed: Maybe
Error Code: 0
Call: SQLCall(INSERT INTO WEATHER (ID, MESSAGE) VALUES (?, ?))
+Query: InsertObjectQuery(example.remoteejb.entity.Weather[id=3])+
at oracle.toplink.essentials.exceptions.DatabaseException.sqlException(DatabaseException.java:305)
at oracle.toplink.essentials.jndi.JNDIConnector.connect(JNDIConnector.java:150)
at oracle.toplink.essentials.sessions.DatasourceLogin.connectToDatasource(DatasourceLogin.java:184)
at oracle.toplink.essentials.internal.databaseaccess.DatasourceAccessor.connect(DatasourceAccessor.java:233)
at com.sun.corba.ee.impl.protocol.giopmsgheaders.RequestMessage_1_2.callback(RequestMessage_1_2.java:223)
at com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.handleRequest(CorbaMessageMediatorImpl.java:806)
at com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.dispatch(CorbaMessageMediatorImpl.java:563)
at com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.doWork(CorbaMessageMediatorImpl.java:2567)
at com.sun.corba.ee.impl.orbutil.threadpool.ThreadPoolImpl$WorkerThread.run(ThreadPoolImpl.java:555)
Caused by: java.sql.SQLException: Error in allocating a connection. Cause: org.omg.CORBA.COMM_FAILURE: vmcid: SUN minor code: 219 completed: Maybe
at com.sun.gjc.spi.base.DataSource.getConnection(DataSource.java:115)
at oracle.toplink.essentials.jndi.JNDIConnector.connect(JNDIConnector.java:145)
+... 54 more+
JTS5054: Unexpected error occurred in after completion
Local Exception Stack:
+Exception [TOPLINK-4002] (Oracle TopLink Essentials - 2.0.1 (Build b04-fcs (04/11/2008))): oracle.toplink.essentials.exceptions.DatabaseException+
Internal Exception: java.sql.SQLException: Error in allocating a connection. Cause: org.omg.CORBA.COMM_FAILURE: vmcid: SUN minor code: 219 completed: Maybe
Error Code: 0
Call: SQLCall(INSERT INTO WEATHER (ID, MESSAGE) VALUES (?, ?))
+Query: InsertObjectQuery(example.remoteejb.entity.Weather[id=3])+
at oracle.toplink.essentials.exceptions.DatabaseException.sqlException(DatabaseException.java:305)
at oracle.toplink.essentials.jndi.JNDIConnector.connect(JNDIConnector.java:150)
at oracle.toplink.essentials.sessions.DatasourceLogin.connectToDatasource(DatasourceLogin.java:184)
at oracle.toplink.essentials.internal.databaseaccess.DatasourceAccessor.connect(DatasourceAccessor.java:233)
at oracle.toplink.essentials.internal.databaseaccess.DatabaseAccessor.connect(DatabaseAccessor.java:242)
at com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.dispatch(CorbaMessageMediatorImpl.java:563)
at com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.doWork(CorbaMessageMediatorImpl.java:2567)
at com.sun.corba.ee.impl.orbutil.threadpool.ThreadPoolImpl$WorkerThread.run(ThreadPoolImpl.java:555)
Caused by: java.sql.SQLException: Error in allocating a connection. Cause: org.omg.CORBA.COMM_FAILURE: vmcid: SUN minor code: 219 completed: Maybe
at com.sun.gjc.spi.base.DataSource.getConnection(DataSource.java:115)
at oracle.toplink.essentials.jndi.JNDIConnector.connect(JNDIConnector.java:145)
+... 54 more+
TX afterCompletion callback, status=ROLLEDBACK
release unit of work
initialize identitymaps
client released
The HelloWorld-ejb making the remote call to Niceweather-ejb has the log
+LDR5010: All ejb(s) of [HelloEJB] loaded successfully!+
+"IOP00410219: (COMM_FAILURE) Communications timeout waiting for response. Exceeded 1,800,000 milliseconds"+
org.omg.CORBA.COMM_FAILURE: vmcid: SUN minor code: 219 completed: Maybe
at com.sun.corba.ee.impl.logging.ORBUtilSystemException.communicationsTimeoutWaitingForResponse(ORBUtilSystemException.java
+.... cut .....+
at com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.doWork(CorbaMessageMediatorImpl.java:2567)
at com.sun.corba.ee.impl.orbutil.threadpool.ThreadPoolImpl$WorkerThread.run(ThreadPoolImpl.java:555)
+JTS5033: Exception [org.omg.CORBA.COMM_FAILURE: vmcid: SUN minor code: 219 completed: Maybe] on [before_completion] synchronization operation.+
+EJB5018: An exception was thrown during an ejb invocation on [HelloBean]+
javax.ejb.EJBException: Transaction aborted; nested exception is: javax.transaction.RollbackException
javax.transaction.RollbackException
at com.sun.jts.jta.TransactionManagerImpl.commit(TransactionManagerImpl.java:311)
+.... cut .....+
Similar Messages
-
I've got the following in my orion-ejb-jar.xml:
<session-deployment name="..." transaction-timeout="900"/>
OC4J appears to ignore it. For one, I get transaction timeouts with operations lasting less than 900 seconds. For two, I see in the EM MBean browser that the transaction timeout for the stateless session bean has a value of "-1".
Am I doing something wrong, or is OC4J broken?Anybody out there?
I'm sure I can't be the only one trying to do this... -
Problem with transacted JMS connection factory and transaction timeouts
We encountered an interesting problem using transacted JMS connection factories.
An EJB starts a container managed transaction and tries to validate a credit card
before creating some information to a database for the user, in case of success
an SMS is sent to the user via the transacted JMS queue. If the credit card authentications
duration is about the same as the transactions timeout (in this case the default
30 seconds) sometimes the database inserts is committed but the JMS insert is
rollbacked. How can this be?
If the authorization duration is much longer than 30 seconds everything works
fine (both database and JMS inserts rollbacked), the same is true if a rollback
is insured by calling EJBContext.setRollbackOnly(). The problem thus occurs only
if the duration is approximately the same as the transaction timeout, it appears
that the database insert is not timeouted but the JMS insert is. How can this
be if they are both participating in the same transaction.
The JMSConnectionFactory used is a Connection factory with XA-enabled. The result
is the same also with the default "javax.jms.QueueConnectionFactory" and if we
configure our own factory with user transactions enabled.
Any help appreciated!
Tomas Granö wrote:
> We encountered an interesting problem using transacted JMS connection factories.
> An EJB starts a container managed transaction and tries to validate a credit card
> before creating some information to a database for the user, in case of success
> an SMS is sent to the user via the transacted JMS queue. If the credit card authentications
> duration is about the same as the transactions timeout (in this case the default
> 30 seconds) sometimes the database inserts is committed but the JMS insert is
> rollbacked. How can this be?
It should not be.
>
> If the authorization duration is much longer than 30 seconds everything works
> fine (both database and JMS inserts rollbacked), the same is true if a rollback
> is insured by calling EJBContext.setRollbackOnly(). The problem thus occurs only
> if the duration is approximately the same as the transaction timeout, it appears
> that the database insert is not timeouted but the JMS insert is. How can this
> be if they are both participating in the same transaction.
>
> The JMSConnectionFactory used is a Connection factory with XA-enabled. The result
> is the same also with the default "javax.jms.QueueConnectionFactory" and if we
> configure our own factory with user transactions enabled.
>
> Any help appreciated!
Make sure that your session is not "transacted". In other words,
the first parameter to createSession() must be false. There is an
unfortunate name re-use here. If a session is "transacted", it
maintains an independent "inner transaction" independent of the
outer transaction. From the above description, it seems unlikely
that your application has this wrong, as you say that
"setRollbackOnly" works - but please check anyway.
Make sure that you are using a true XA capable driver and database
(XA "emulation" may not suffice)
Beyond the above, I do not see what can be going wrong. You
may want to try posting to the transactions and jdbc newsgroups. Note
that JMS is appears to be exhibiting the correct behavior, but the
JDBC operation is not. The JDBC operation appears to have
its timeout independent of the transaction monitor's timeout.
Tom
-
Full Deployment failing with Transaction timeout
Hi
I am trying to do a full deployment(ATG 10.0.2) and its failing with the same transaction timeout on all environments (local, dev, stage)
I have tried to reduce the maxThreads to 1 in DeploymentManager but still i get the same exception.
Incremental deployments seems to be running fine if i deploy anything, like category, products, skus.
Even the catalog feed runs and deploys fine.
I have a total of around 1500 products and 7000 skus.
In BCC screen i see it gives timeout while deploying skus
Error Deployment Failed 1051226:sku 2011-08-27 20:04:02.798
Message Detail:
CONTAINER:atg.deployment.DistributedDeploymentException; SOURCE:CONTAINER:atg.repository.RepositoryException; SOURCE:org.jboss.util.NestedSQLException: Transaction is not active: tx=TransactionImple < ac, BasicAction: ada0e22:4593:4e59847c:5e57e8 status: ActionStatus.ABORTING >; - nested throwable: (javax.resource.ResourceException: Transaction is not active: tx=TransactionImple < ac, BasicAction: ada0e22:4593:4e59847c:5e57e8 status: ActionStatus.ABORTING >) at atg.deployment.repository.RepositoryWorkerThread.processMarkerForReferenceUpdatePhase(RepositoryWorkerThread.java:346) at atg.deployment.DeploymentWorkerThread.processMarkerPhase(DeploymentWorkerThread.java:540) at atg.deployment.DeploymentWorkerThread.run(DeploymentWorkerThread.java:307)
In the logs i see the following exceptions::
20:03:54,827 WARN [arjLoggerI18N] [com.arjuna.ats.arjuna.coordinator.BasicAction_58] - Abort of action id ada0e22:4593:4e59847c:5e57e8 invoked while multiple threads a
ctive within it.
20:03:54,827 WARN [arjLoggerI18N] [com.arjuna.ats.arjuna.coordinator.CheckedAction_2] - CheckedAction::check - atomic action ada0e22:4593:4e59847c:5e57e8 aborting with
1 threads active!
20:03:55,329 WARN [arjLoggerI18N] [com.arjuna.ats.arjuna.coordinator.TransactionReaper_18] - TransactionReaper::check timeout for TX ada0e22:4593:4e59847c:5e57e8 in st
ate CANCEL
20:03:55,831 WARN [arjLoggerI18N] [com.arjuna.ats.arjuna.coordinator.TransactionReaper_18] - TransactionReaper::check timeout for TX ada0e22:4593:4e59847c:5e57e8 in st
ate CANCEL_INTERRUPTED
20:03:55,831 WARN [arjLoggerI18N] [com.arjuna.ats.arjuna.coordinator.TransactionReaper_6] - TransactionReaper::check worker Thread[Thread-138,5,jboss] not responding t
o interrupt when cancelling TX ada0e22:4593:4e59847c:5e57e8 -- worker marked as zombie and TX scheduled for mark-as-rollback
20:03:55,831 WARN [arjLoggerI18N] [com.arjuna.ats.arjuna.coordinator.TransactionReaper_11] - TransactionReaper::check failed to mark TX ada0e22:4593:4e59847c:5e57e8 a
s rollback only
20:04:01,934 INFO [DeploymentManager] DEBUG RepositoryWorkerThread-1(Reference Update Phase) Rolling Back Current Transaction
20:04:02,021 WARN [arjLoggerI18N] [com.arjuna.ats.arjuna.coordinator.BasicAction_40] - Abort called on already aborted atomic action ada0e22:4593:4e59847c:5e57e8
20:04:02,022 WARN [arjLoggerI18N] [com.arjuna.ats.arjuna.coordinator.TransactionReaper_13] - TransactionReaper::doCancellations worker Thread[Thread-138,5,jboss] misse
d interrupt when cancelling TX ada0e22:4593:4e59847c:5e57e8 -- exiting as zombie (zombie count decremented to 0)
20:04:02,023 INFO [DeploymentManager] DEBUG RepositoryWorkerThread-1(Reference Update Phase) Committing 237 markers, 1 failed markers
20:04:02,798 ERROR [DeploymentManager] item = repositoryMarker:mark876015 cause = CONTAINER:atg.deployment.DistributedDeploymentException; SOURCE:CONTAINER:atg.reposit
ory.RepositoryException; SOURCE:org.jboss.util.NestedSQLException: Transaction is not active: tx=TransactionImple < ac, BasicAction: ada0e22:4593:4e59847c:5e57e8 status
: ActionStatus.ABORTING >; - nested throwable: (javax.resource.ResourceException: Transaction is not active: tx=TransactionImple < ac, BasicAction: ada0e22:4593:4e59847
c:5e57e8 status: ActionStatus.ABORTING >)
at atg.deployment.repository.RepositoryWorkerThread.processMarkerForReferenceUpdatePhase(RepositoryWorkerThread.java:346)
at atg.deployment.DeploymentWorkerThread.processMarkerPhase(DeploymentWorkerThread.java:540)
at atg.deployment.DeploymentWorkerThread.run(DeploymentWorkerThread.java:307)
message = Deployment Failed time = Sat Aug 27 20:04:02 MDT 2011 atg.deployment.DeploymentFailure@2be5134e
CAUGHT AT:
CONTAINER:atg.deployment.DistributedDeploymentException; SOURCE:CONTAINER:atg.repository.RepositoryException; SOURCE:org.jboss.util.NestedSQLException: Transaction is n
ot active: tx=TransactionImple < ac, BasicAction: ada0e22:4593:4e59847c:5e57e8 status: ActionStatus.ABORTING >; - nested throwable: (javax.resource.ResourceException: T
ransaction is not active: tx=TransactionImple < ac, BasicAction: ada0e22:4593:4e59847c:5e57e8 status: ActionStatus.ABORTING >)
at atg.deployment.repository.RepositoryWorkerThread.processMarkerForReferenceUpdatePhase(RepositoryWorkerThread.java:346)
20:04:02,992 INFO [DeploymentManager] DEBUG RepositoryWorkerThread-1(Reference Update Phase) Failure count was: 0. New failure count is: 1.
20:04:02,995 INFO [DeploymentManager] DEBUG RepositoryWorkerThread-1(Reference Update Phase) Rolling Back Current Transaction
20:04:02,995 INFO [DeploymentManager] DEBUG RepositoryWorkerThread-1(Reference Update Phase) Committing 0 markers, 0 failed markers
20:04:03,152 INFO [DeploymentManager] DEBUG RepositoryWorkerThread-1(Reference Update Phase) Exiting normally
20:04:03,153 ERROR [DeploymentManager] Unexpected error occurred. DeploymentWorkerThread terminated prematurely.
atg.deployment.DistributedDeploymentException: Exceeded allowable error count (0)
at atg.deployment.DeploymentWorkerThread.processMarkerPhase(DeploymentWorkerThread.java:652)
at atg.deployment.DeploymentWorkerThread.run(DeploymentWorkerThread.java:307)
20:04:07,724 INFO [DeploymentServer] DEBUG 1500007:Production:atg.deployment.adapter.DistributedDeploymentAdapter.displayDeploymentFailures(DistributedDeploymentAdapte
r.java:2652) found 1 failure messages
20:04:07,747 INFO [DeploymentServer] DEBUG 1500007:Production:atg.deployment.adapter.DistributedDeploymentAdapter.displayDeploymentFailures(DistributedDeploymentAdapte
r.java:2683) adding failure message Deployment Failed with severity Error
20:04:11,211 INFO [DeploymentManager] DEBUG Main deployment thread: No waiting deployments to start
20:04:11,240 INFO [DeploymentServer] DEBUG 1500007:Production:atg.deployment.adapter.DistributedDeploymentAdapter.deploymentFailed(DistributedDeploymentAdapter.java:31
86) DeploymentListener.deploymentFailed called for deployment with ID: 1500007
20:04:11,240 INFO [DeploymentServer] DEBUG 1500007:Production:atg.deployment.adapter.DistributedDeploymentAdapter.deploymentFailed(DistributedDeploymentAdapter.java:31
94) DAFDeploymentID: 1500007 matches DeploymmentID: 1500007
20:04:11,240 INFO [DeploymentServer] DEBUG 1500007:Production:atg.deployment.adapter.DistributedDeploymentAdapter.deploymentFailed(DistributedDeploymentAdapter.java:31
98) DeploymentListener.deploymentFailed
20:04:11,241 INFO [DeploymentServer] DEBUG 1500007:Production:atg.deployment.adapter.DistributedDeploymentAdapter.displayDeploymentFailures(DistributedDeploymentAdapte
r.java:2652) found 1 failure messages
20:04:11,259 INFO [DeploymentServer] DEBUG 1500007:Production:atg.deployment.adapter.DistributedDeploymentAdapter.displayDeploymentFailures(DistributedDeploymentAdapte
r.java:2683) adding failure message Deployment Failed with severity Error
20:04:11,261 INFO [DeploymentServer] DEBUG 1500007:Production:atg.deployment.adapter.DistributedDeploymentAdapter.deployData(DistributedDeploymentAdapter.java:2197)
deployment failed
20:04:11,386 ERROR [DeploymentServer]
atg.deployment.common.DeploymentException: Deployment '1500007' to target 'Production' encountered a system level deployment error during data transfer.
at atg.deployment.common.ResourceUtil.exception(ResourceUtil.java:306)
at atg.deployment.adapter.DistributedDeploymentAdapter.deployData(DistributedDeploymentAdapter.java:2238)
at atg.deployment.adapter.DistributedDeploymentAdapter.transferData(DistributedDeploymentAdapter.java:305)
at atg.deployment.server.Deployment.run(Deployment.java:1688)I am using ATG10.0.2 with jboss-5.1-eap
I have tried increasing the timeout on jboss, but it only stops the timeout from happening, but the full deployment takes forever and takes more than 12 hours.
The catalog itself is too small and shouldnt be taking that much at all.
I just checked one thing:
I have a one to many relation with my sku and sale price(custom table) which has 11000 rows. If i delete the data in this table the deployment happens fine and takes about 30 mins.
The relationship it self seems correct.
this is on sku descriptor
<table name="my_sku_saleprice" type="multi" id-column-name="sku_id">
<property name="salePrices" column-name="sale_prices" data-type="set" component-item-type="salePrices" display-name-resource="salePrices"
writable="true" category-resource="categoryPresentation">
<attribute name="resourceBundle" value="atg.projects.store.StoreCatalogTemplateResources"/>
</property>
</table>
And this is the salePrices descriptor
<item-descriptor name="salePrices" display-name-resource="itemDescriptorSalePrices"
item-cache-size="100000" query-cache-size="100000">
<attribute name="resourceBundle" value="atg.projects.store.StoreCatalogTemplateResources"/>
<table name="my_sku_saleprices" type="primary" id-column-name="sale_prices">
<property name="salesPrice" data-type="double" column-name="sales_price" required="true" display-name-resource="salesPrice"/>
<property name="saleType" data-type="string" column-name="sale_type" required="true" display-name-resource="saleType"/>
<property name="startDate" data-type="Date" column-name="start_date" display-name-resource="startDate"/>
<property name="endDate" data-type="Date" column-name="end_date" display-name-resource="endDate"/>
</table>
</item-descriptor>
The only thing i m not able to understand is why its taking forever to get the full deployment.
Incremental deployment in catalog happens quickly, if i deploy any sku,product or anything.
Is it something to do with ATG or jboss?
Any pointers will help
Thanks -
Hello,
Does anybody knows what the behavior should be for a Session EJB with BMT (using JTA) after a transaction timeout? Does the container performs a database rollback for you immediately after the time-out event? I’ve noticed that JBoss does not perform a rollback but Web does. What do the J2EE specs say what should happen?
We are experiencing database locks in an Oracle database caused by ‘hanging’ JTA-transactions which aren’t removed after a timeout. An application server restart will remove them. We are trying to find the cause, there fore I’am posting this message.
Regards,
Marteyn Heijlaerts"Laurel Neustadter" <[email protected]> wrote:
>
>Hi:
>
>The WLS 6.0 documentation states that for a CMT bean, one specifies the
>transaction
>timeout in weblogic-ejb-jar.xml, and for a BMT bean, one specifies the
>transaction
>timeout via UserTransaction.setTransactionTimeout().
>
>You also set a transaction timeout attribute at the domain level. How
>does the
>domain level attribute work into all of this? How is it used?
>
>For example, if a transaction timeout value is not specified at the bean
>level,
>will the domain level value be used?
>
>Laurel
Yes, the domain level timeout is the default.
It is overridden by any setting at the EJB level. This in turn
can be overridden by the client calling the EJB, if the client
starts a transaction and uses
transactionManager.setTransactionTimeout()
-
Hi,
From a bean's method whose transaction attribute is marked as
<Required>, I call another bean whose transaction attribute is marked as
<RequiresNew> (container managed transactions). When the container
suspends the first transaction and starts the second one, is the timeout
counter for the first transaction still ticking or is it also suspended
and resumed after the second transaction completes ?
Thanks, alex.
PS: I'm using WL6.0 (no servcie pack).
Alex Vauthey wrote:
> Bad news for us...
>
> We have a 'gateway' generic session bean that we use to run all business
> requests which in turn can call other session beans or entity beans. So
> the timeout of my 'gateway' session bean has to have a timeout value
> that is the highest possible sum of the timeouts of all called beans ?
> That's bad, because in some cases the gateway should execute quite quickly.
>
It sounds like your gateway bean needs different semantics. It probably
shouldn't hold open a transaction while it calls the other beans.
It's hard to tell you what to do without more info, but bean-managed
transactions possibly with a compensating transaction may be the way to go.
> I'm disappointed the ejb specs did not specify what 'suspended' really
> means... So each container vendor has its very own idea of what
> 'suspended' means, I suppose.
Not really. EJB just has a flat transaction model.
-- Rob
>
> Any idea to cope with that problem without breaking the generic gateway
> approach ?
>
> Rgrds, alex.
>
> Rob Woollen wrote:
>
>> The timer keeps ticking. Suspend is a bad name for this because
>> really the transaction is still active, it's just no longer associated
>> with the current thread.
>>
>> -- Rob
>>
>> PS WLS 6.0 no service pack is a bad way to go. We've fixed lots of
>> bugs since then. I'd suggest 6.1SP3 or 7.0.
>>
>>
>> Alex Vauthey wrote:
>>
>>> Hi,
>>>
>>> From a bean's method whose transaction attribute is marked as
>>> <Required>, I call another bean whose transaction attribute is marked
>>> as <RequiresNew> (container managed transactions). When the container
>>> suspends the first transaction and starts the second one, is the
>>> timeout counter for the first transaction still ticking or is it also
>>> suspended and resumed after the second transaction completes ?
>>>
>>> Thanks, alex.
>>>
>>> PS: I'm using WL6.0 (no servcie pack).
>>
>>
>
> --
>
> Alexandre Vauthey
> Server Technology Mgr.
> Application Networks
> 444 Ramona Street
> Palo Alto, CA 94301
>
> Tel: 1 (650) 462 7224
> Fax: 1 (650) 462 7221
>
> www.application-networks.com <http://www.application-networks.com/>*
> <http://www.application-networks.com/>*
>
>
> <http://www.application-networks.com/>
>
> *
> <http://www.application-networks.com/>*
>
>
>
>
-
Transaction timeouts behaviour - explanation needed
Hello all,
I'm a newbie to Weblogic and would like to understand how transaction timeouts work in Weblogic. I have a EJB2 application running under Weblogic 10.3 and using Oracle 11g database via thin jdbc driver.
I noticed that if I set trans-timeout-seconds in deployment descriptor it terminates sql queries if they overflow the limit. Say I have timeout set to 10 seconds, it will stop executing sql query after that time and immediately return exception to caller of the current EJB method. This is just perfect!
What I want is to understand how that is done, does it proxy driver somehow? Will it work with other databases, Postgresql for example?
Can I port same behavior to other app servers, JBoss for example.
Thank you in advance.Unfortunately, it seems to work different in JBoss7. I created a very simple app and it waits until end of query execution instead of interrupting it.
I'm porting application from weblogic to JBoss7 and it is critical for me to achieve identical behavior. -
Transaction Timeout (BPEL v10.1.2.0.0, WebLogic 8.1 sp4)
We are attempting to process a transform on a medium sized xml doc (~4.5 MB). For the test case we are simply reading the the doc using the FileAdapter, performing a transformation, and then writing the result to a file using the FileAdapter once again. The flow works fine for smallish files (under ~4MB), however, when dropping a file greater than that size the flow fails once finished while writing entries to the BPEL audit log with a TransactionTimedOutException (see exception below).
I understand what is happening and why (it certainly takes longer than 2 mins to process the file). I have also done quite a bit of digging around for references to this issue and found several posts regarding bumping the transaction timeout value when running the OC4J container. My problem is that we are not running the OC4J container. I know how to manage the default transaction timeout value for WebLogic but it appears that the BPEL application doesn't seem to be honoring the default transaction timeout on the WL Server. I have come to this conclusion for two reasons: first, the default transaction timeout on the WL Server (before modification) is 30 seconds, not the 120 seconds that this transaction is timing out on. second, changing the transaction timeout value on the WebLogic server has no impact on this issue what so ever. I can set the transaction timeout to any value I like, the process ALWAYS times out after 120 seconds.
Is there another setting on the BPEL server that I may have missed that is overriding the default timeout, i.e. is it possible that when the BPEL server process is starting the transaction it is setting the timeout on the TransactionManager in code prior to starting the transaction?
Any pointers are greatly appreciated.
------------- START STACK TRACE ------------------
<2007-03-15 13:50:24,625> <ERROR> <default.collaxa.cube> <BaseCubeSessionBean::logError> Error while invoking bean "cube delivery": Cannot insert audit trail.
The process domain was unable to insert the current log entries for the instance "10601" to the audit trail table. The exception reported is: The transaction is no longer active - status: 'Rolled back. [Reason=weblogic.transaction.internal.TimedOutException: Transaction timed out after 120 seconds
Name=[EJB com.collaxa.cube.engine.ejb.impl.CubeDeliveryBean.handleInvoke(java.lang.String,com.oracle.bpel.client.auth.DomainAuth)],Xid=BEA1-0021B65431A170F9CFEF(31469464),Status=Active,numRepliesOwedMe=0,numRepliesOwedOthers=0,seconds since begin=120,seconds left=60,activeThread=Thread[ExecuteThread: '9' for queue: 'default',5,Thread Group for Queue: 'default'],XAServerResourceInfo[weblogic.jdbc.wrapper.JTSXAResourceImpl]=(ServerResourceInfo[weblogic.jdbc.wrapper.JTSXAResourceImpl]=(state=ended,assigned=none),xar=weblogic.jdbc.wrapper.JTSXAResourceImpl@154d033,re-Registered = false),SCInfo[f58_integration+orabpelServer]=(state=active),properties=({weblogic.transaction.name=[EJB com.collaxa.cube.engine.ejb.impl.CubeDeliveryBean.handleInvoke(java.lang.String,com.oracle.bpel.client.auth.DomainAuth)], weblogic.jdbc=t3://127.0.0.1:9700}),OwnerTransactionManager=ServerTM[ServerCoordinatorDescriptor=(CoordinatorURL=orabpelServer+127.0.0.1:9700+f58_integration+t3+, XAResources={},NonXAResources={})],CoordinatorURL=orabpelServer+127.0.0.1:9700+f58_integration+t3+)]'. No further JDBC access is allowed within this transaction.
Please check that the machine hosting the datasource is physically connected to the network. Otherwise, check that the datasource connection parameters (user/password) is currently valid.
sql statement: INSERT INTO audit_trail( cikey, domain_ref, count_id, block, block_csize, block_usize, log ) VALUES( ?, ?, ?, ?, ?, ?, ? )
<2007-03-15 13:50:24,643> <ERROR> <default.collaxa.cube.engine.dispatch> <BaseScheduledWorker::process> Failed to handle dispatch message ... exception ORABPEL-05002
Message handle error.
An exception occurred while attempting to process the message "com.collaxa.cube.engine.dispatch.message.invoke.InvokeInstanceMessage"; the exception is: Transaction Rolledback.: weblogic.transaction.internal.TimedOutException: Transaction timed out after 120 seconds
Name=[EJB com.collaxa.cube.engine.ejb.impl.CubeDeliveryBean.handleInvoke(java.lang.String,com.oracle.bpel.client.auth.DomainAuth)],Xid=BEA1-0021B65431A170F9CFEF(31469464),Status=Active,numRepliesOwedMe=0,numRepliesOwedOthers=0,seconds since begin=120,seconds left=60,activeThread=Thread[ExecuteThread: '9' for queue: 'default',5,Thread Group for Queue: 'default'],XAServerResourceInfo[weblogic.jdbc.wrapper.JTSXAResourceImpl]=(ServerResourceInfo[weblogic.jdbc.wrapper.JTSXAResourceImpl]=(state=ended,assigned=none),xar=weblogic.jdbc.wrapper.JTSXAResourceImpl@154d033,re-Registered = false),SCInfo[f58_integration+orabpelServer]=(state=active),properties=({weblogic.transaction.name=[EJB com.collaxa.cube.engine.ejb.impl.CubeDeliveryBean.handleInvoke(java.lang.String,com.oracle.bpel.client.auth.DomainAuth)], weblogic.jdbc=t3://127.0.0.1:9700}),OwnerTransactionManager=ServerTM[ServerCoordinatorDescriptor=(CoordinatorURL=orabpelServer+127.0.0.1:9700+f58_integration+t3+, XAResources={},NonXAResources={})],CoordinatorURL=orabpelServer+127.0.0.1:9700+f58_integration+t3+)
at weblogic.transaction.internal.ServerTransactionImpl.wakeUp(ServerTransactionImpl.java:1614)
at weblogic.transaction.internal.ServerTransactionManagerImpl.processTimedOutTransactions(ServerTransactionManagerImpl.java:1117)
at weblogic.transaction.internal.TransactionManagerImpl.wakeUp(TransactionManagerImpl.java:1881)
at weblogic.transaction.internal.ServerTransactionManagerImpl.wakeUp(ServerTransactionManagerImpl.java:1034)
at weblogic.transaction.internal.WLSTimer.trigger(WLSTimer.java:31)
at weblogic.time.common.internal.ScheduledTrigger.run(ScheduledTrigger.java:243)
at weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubject.java:321)
at weblogic.security.service.SecurityManager.runAs(SecurityManager.java:121)
at weblogic.time.common.internal.ScheduledTrigger.executeLocally(ScheduledTrigger.java:229)
at weblogic.time.common.internal.ScheduledTrigger.execute(ScheduledTrigger.java:223)
at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:219)
at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:178)
; nested exception is: weblogic.transaction.internal.TimedOutException: Transaction timed out after 120 seconds
Name=[EJB com.collaxa.cube.engine.ejb.impl.CubeDeliveryBean.handleInvoke(java.lang.String,com.oracle.bpel.client.auth.DomainAuth)],Xid=BEA1-0021B65431A170F9CFEF(31469464),Status=Active,numRepliesOwedMe=0,numRepliesOwedOthers=0,seconds since begin=120,seconds left=60,activeThread=Thread[ExecuteThread: '9' for queue: 'default',5,Thread Group for Queue: 'default'],XAServerResourceInfo[weblogic.jdbc.wrapper.JTSXAResourceImpl]=(ServerResourceInfo[weblogic.jdbc.wrapper.JTSXAResourceImpl]=(state=ended,assigned=none),xar=weblogic.jdbc.wrapper.JTSXAResourceImpl@154d033,re-Registered = false),SCInfo[f58_integration+orabpelServer]=(state=active),properties=({weblogic.transaction.name=[EJB com.collaxa.cube.engine.ejb.impl.CubeDeliveryBean.handleInvoke(java.lang.String,com.oracle.bpel.client.auth.DomainAuth)], weblogic.jdbc=t3://127.0.0.1:9700}),OwnerTransactionManager=ServerTM[ServerCoordinatorDescriptor=(CoordinatorURL=orabpelServer+127.0.0.1:9700+f58_integration+t3+, XAResources={},NonXAResources={})],CoordinatorURL=orabpelServer+127.0.0.1:9700+f58_integration+t3+)
------------- END STACK TRACE ------------------Hi
i am facing a similar problem..did u find the solution for this problem?
Please pass the solution/workaround u performed for solving this...
Thanks & Regards
Subramanian -
Transaction timeout for FTP Put as an attachment
Hi,
When I am trying to get a file from E Business Suite(Oracle Apps) and place the same in to FTP Outbound as an attachment, I am getting the below exception. This did not happen in PS2 but it is happening in PS3(11.11.1.4) with the same code, can some please me on this. The file size is around 16MB. I have restriction to increase the transaction timeout value in the through admin server.
java.sql.SQLException: Unexpected exception while enlisting XAConnection java.sql.SQLException: Transaction rolled back: Transaction timed out after 299 seconds BEA1-0672B035E0F02A163299 at weblogic.jdbc.jta.DataSource.enlist(DataSource.java:1616) at weblogic.jdbc.jta.DataSource.refreshXAConnAndEnlist(DataSource.java:1503) at weblogic.jdbc.wrapper.JTAConnection.getXAConn(JTAConnection.java:205) at weblogic.jdbc.wrapper.JTAConnection.checkConnection(JTAConnection.java:74) at weblogic.jdbc.wrapper.JTAConnection.checkConnection(JTAConnection.java:65) at weblogic.jdbc.wrapper.Connection.preInvocationHandler(Connection.java:94) at weblogic.jdbc.wrapper.Connection.prepareStatement(Connection.java:496) at oracle.integration.platform.xml.XMLDocumentManagerImpl.insertDocument(XMLDocumentManagerImpl.java:648) at oracle.integration.platform.xml.XMLDocumentManagerImpl.insertDocument(XMLDocumentManagerImpl.java:185) at sun.reflect.GeneratedMethodAccessor2001.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:307) at org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:182) at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:149) at org.springframework.transaction.interceptor.TransactionInterceptor.invoke(TransactionInterceptor.java:106) at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:171) at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204) at $Proxy336.insertDocument(Unknown Source) at oracle.integration.platform.instance.store.MessageStore.savePayload(MessageStore.java:248) at oracle.integration.platform.instance.store.MessageStore.savePayloads(MessageStore.java:102) at oracle.integration.platform.instance.InstanceManagerImpl.persistPayloads(InstanceManagerImpl.java:798) at oracle.integration.platform.instance.InstanceManagerImpl.persistReferenceInstanceBean(InstanceManagerImpl.java:1150) at oracle.integration.platform.blocks.adapter.AbstractAdapterBindingComponent.createAndPersistBindingInstance(AbstractAdapterBindingComponent.java:504) at oracle.integration.platform.blocks.adapter.AdapterReference.createAndPersistBindingInstance(AdapterReference.java:357) at oracle.integration.platform.blocks.adapter.AdapterReference.createBindingInstance(AdapterReference.java:331) at oracle.integration.platform.blocks.adapter.AdapterReference.post(AdapterReference.java:253) at oracle.integration.platform.blocks.mesh.AsynchronousMessageHandler.doPost(AsynchronousMessageHandler.java:142) at oracle.integration.platform.blocks.mesh.MessageRouter.post(MessageRouter.java:194) at oracle.integration.platform.blocks.mesh.MeshImpl.post(MeshImpl.java:215) at sun.reflect.GeneratedMethodAccessor3279.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:307) at org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:182) at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:149) at oracle.integration.platform.metrics.PhaseEventAspect.invoke(PhaseEventAspect.java:71) at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:171) at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204) at $Proxy333.post(Unknown Source) at oracle.fabric.CubeServiceEngine.postToMesh(CubeServiceEngine.java:806) at com.collaxa.cube.ws.WSInvocationManager.invoke(WSInvocationManager.java:258) at com.collaxa.cube.engine.ext.common.InvokeHandler.__invoke(InvokeHandler.java:1056) at com.collaxa.cube.engine.ext.common.InvokeHandler.handleNormalInvoke(InvokeHandler.java:583) at com.collaxa.cube.engine.ext.common.InvokeHandler.handle(InvokeHandler.java:130) at com.collaxa.cube.engine.ext.bpel.common.wmp.BPELInvokeWMP.__executeStatements(BPELInvokeWMP.java:74) at com.collaxa.cube.engine.ext.bpel.common.wmp.BaseBPELActivityWMP.perform(BaseBPELActivityWMP.java:158) at com.collaxa.cube.engine.CubeEngine._performActivity(CubeEngine.java:2463) at com.collaxa.cube.engine.CubeEngine.performActivity(CubeEngine.java:2334) at com.collaxa.cube.engine.CubeEngine.handleWorkItem(CubeEngine.java:1115) at com.collaxa.cube.engine.dispatch.message.instance.PerformMessageHandler.handleLocal(PerformMessageHandler.java:73) at com.collaxa.cube.engine.dispatch.DispatchHelper.handleLocalMessage(DispatchHelper.java:220) at com.collaxa.cube.engine.dispatch.DispatchHelper.sendMemory(DispatchHelper.java:328) at com.collaxa.cube.engine.CubeEngine.endRequest(CubeEngine.java:4350) at com.collaxa.cube.engine.CubeEngine.endRequest(CubeEngine.java:4281) at com.collaxa.cube.engine.CubeEngine.createAndInvoke(CubeEngine.java:679) at com.collaxa.cube.engine.delivery.DeliveryService.handleInvoke(DeliveryService.java:654) at com.collaxa.cube.engine.ejb.impl.CubeDeliveryBean.handleInvoke(CubeDeliveryBean.java:293) at sun.reflect.GeneratedMethodAccessor6353.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at com.bea.core.repackaged.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:310) at com.bea.core.repackaged.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:182) at com.bea.core.repackaged.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:149) at com.bea.core.repackaged.springframework.jee.intercept.MethodInvocationInvocationContext.proceed(MethodInvocationInvocationContext.java:104) at oracle.security.jps.ee.ejb.JpsAbsInterceptor$1.run(JpsAbsInterceptor.java:94) at oracle.security.jps.util.JpsSubject.doAsPrivileged(JpsSubject.java:313) at oracle.security.jps.ee.util.JpsPlatformUtil.runJaasMode(JpsPlatformUtil.java:413) at oracle.security.jps.ee.ejb.JpsAbsInterceptor.runJaasMode(JpsAbsInterceptor.java:81) at oracle.security.jps.ee.ejb.JpsAbsInterceptor.intercept(JpsAbsInterceptor.java:112) at oracle.security.jps.ee.ejb.JpsInterceptor.intercept(JpsInterceptor.java:105) at sun.reflect.GeneratedMethodAccessor1143.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at com.bea.core.repackaged.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:310) at com.bea.core.repackaged.springframework.jee.intercept.JeeInterceptorInterceptor.invoke(JeeInterceptorInterceptor.java:69) at com.bea.core.repackaged.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:171) at com.bea.core.repackaged.springframework.aop.support.DelegatingIntroductionInterceptor.doProceed(DelegatingIntroductionInterceptor.java:131) at com.bea.core.repackaged.springframework.aop.support.DelegatingIntroductionInterceptor.invoke(DelegatingIntroductionInterceptor.java:119) at com.bea.core.repackaged.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:171) at com.bea.core.repackaged.springframework.jee.spi.MethodInvocationVisitorImpl.visit(MethodInvocationVisitorImpl.java:37) at weblogic.ejb.container.injection.EnvironmentInterceptorCallbackImpl.callback(EnvironmentInterceptorCallbackImpl.java:54) at com.bea.core.repackaged.springframework.jee.spi.EnvironmentInterceptor.invoke(EnvironmentInterceptor.java:50) at com.bea.core.repackaged.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:171) at com.bea.core.repackaged.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:89) at com.bea.core.repackaged.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:171) at com.bea.core.repackaged.springframework.aop.support.DelegatingIntroductionInterceptor.doProceed(DelegatingIntroductionInterceptor.java:131) at com.bea.core.repackaged.springframework.aop.support.DelegatingIntroductionInterceptor.invoke(DelegatingIntroductionInterceptor.java:119) at com.bea.core.repackaged.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:171) at com.bea.core.repackaged.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204) at $Proxy316.handleInvoke(Unknown Source) at com.collaxa.cube.engine.ejb.impl.bpel.BPELDeliveryBean_5k948i_ICubeDeliveryLocalBeanImpl.__WL_invoke(Unknown Source) at weblogic.ejb.container.internal.SessionLocalMethodInvoker.invoke(SessionLocalMethodInvoker.java:39) at com.collaxa.cube.engine.ejb.impl.bpel.BPELDeliveryBean_5k948i_ICubeDeliveryLocalBeanImpl.handleInvoke(Unknown Source) at com.collaxa.cube.engine.dispatch.message.invoke.InvokeInstanceMessageHandler.handle(InvokeInstanceMessageHandler.java:35) at com.collaxa.cube.engine.dispatch.DispatchHelper.handleMessage(DispatchHelper.java:140) at com.collaxa.cube.engine.dispatch.BaseDispatchTask.process(BaseDispatchTask.java:88) at com.collaxa.cube.engine.dispatch.BaseDispatchTask.run(BaseDispatchTask.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:619) Caused by: weblogic.transaction.TimedOutException: Transaction timed out after 299 seconds BEA1-0672B035E0F02A163299 at weblogic.jdbc.jta.DataSource.enlist(DataSource.java:1614) ... 100 more
Thanks
PrashanthThere is another way but I think it's more complicated.
After reading the file you can use a java code (java embedded activity) and split the file.
For each part of the split you can PUT by FTP the file with append mode. That way your transaction will run in few cycles with less time. -
Weblogic 7 SP5 SQL Exceptions follow a JTA transaction timeout
I have a problem in Weblogic 7 SP5 that was not happening in SP2. I'm using the
Weblogic jDriver (weblogic.jdbc.mssqlserver4.Driver)
I have a transaction that times out due to JTA transaction timeout, and then gets
marked for rollback. For several minutes after the timeout, I get many SQL Exceptions
with bogus messages like "invalid column name" when the column name is, in fact,
correct.
Then the weblogic log file shows "Exception during rollback of transaction" (javax.transaction.SystemException:
Heuristic hazard). Next, the connection is tested on reserve, this test fails,
and the connection is refreshed. As soon as the connection is refreshed, I stop
getting SQL exceptions and everything starts working correctly again.
It seems like the transaction timeout is making the connection go bad, and somehow
other requests are using this bad connection before the transaction finishes rolling
back. What could the problem be? Some excerpts from my app log and weblogic log
are below.
com.workpoint.server.ejb.WorkPointEJBException: The transaction is no longer active
- status: 'Marked rollback. [Reason=weblogic.transaction.internal.TimedOutException:
Transaction timed out after 901 seconds
Name=[EJB com.storeperform.taskmgr.ejb.procrelease.ProcReleaseBean.distributeToOrgUnit(com.storeperform.taskmgr.values.DistributionUnit)],Xid=17109:68c10765ba68aaaa(12114044),Status=Active,numRepliesOwedMe=0,numRepliesOwedOthers=0,seconds
since begin=901,seconds left=60,activeThread=Thread[WorkQueueThread[q=1, qName=ProcReleaseTaskWorkers,
id=6],5,WorkQueueGroup[id=1, name=ProcReleaseTaskWorkers]],ServerResourceInfo[weblogic.jdbc.jts.Connection]=(state=ended,assigned=none,xar=weblogic.jdbc.jts.Connection@18cd616,re-Registered
= false),SCInfo[DomainManager+edwards-s1]=(state=active),properties=({weblogic.transaction.name=[EJB
com.storeperform.taskmgr.ejb.procrelease.ProcReleaseBean.distributeToOrgUnit(com.storeperform.taskmgr.values.DistributionUnit)],
weblogic.jdbc=t3://10.10.3.17:7001}),OwnerTransactionManager=ServerTM[ServerCoordinatorDescriptor=(CoordinatorURL=edwards-s1+10.10.3.17:7001+DomainManager+t3+,
Resources={})],CoordinatorURL=edwards-s1+10.10.3.17:7001+DomainManager+t3+)]'.
No further JDBC access is allowed within this transaction.SQL Command = INSERT
INTO WP_PROCI_NODE_HIST (NODE_HIST_ID, NODE_HIST_DB, PROCI_ID, PROCI_DB, PROCI_NODE_ID,
PROCI_NODE_DB, NODE_ITERATION, NODE_STATE_ID, ROW_VERSION, LU_ID, LU_DATE) VALUES
weblogic.jdbc.mssqlserver4.TdsException: Invalid column name 'user_fname'.
[from weblogic log]
####<Jun 17, 2004 8:14:16 AM MDT> <Error> <EJB> <EDWARDS> <edwards-s1> <WorkQueueThread[q=1,
qName=ProcReleaseTaskWorkers, id=7]> <kernel identity> <> <010025> <Exception
during rollback of transaction Name=[EJB com.storeperform.taskmgr.ejb.procrelease.ProcReleaseBean.distributeToOrgUnit(com.storeperform.taskmgr.values.DistributionUnit)],Xid=17439:68c10765ba68aaaa(31878774),Status=Rolled
back. [Reason=weblogic.transaction.internal.AppSetRollbackOnlyException],HeuristicErrorCode=XA_HEURHAZ,numRepliesOwedMe=0,numRepliesOwedOthers=0,seconds
since begin=3,seconds left=57,ServerResourceInfo[weblogic.jdbc.jts.Connection]=(state=rolledback,assigned=edwards-s1,xar=weblogic.jdbc.jts.Connection@15e1b7e,re-Registered
= false),SCInfo[DomainManager+edwards-s1]=(state=rolledback),properties=({weblogic.transaction.name=[EJB
com.storeperform.taskmgr.ejb.procrelease.ProcReleaseBean.distributeToOrgUnit(com.storeperform.taskmgr.values.DistributionUnit)],
weblogic.jdbc=t3://10.10.3.17:7001}),OwnerTransactionManager=ServerTM[ServerCoordinatorDescriptor=(CoordinatorURL=edwards-s1+10.10.3.17:7001+DomainManager+t3+,
Resources={})],CoordinatorURL=edwards-s1+10.10.3.17:7001+DomainManager+t3+): javax.transaction.SystemException:
Heuristic hazard: (weblogic.jdbc.jts.Connection, HeuristicHazard, (javax.transaction.xa.XAException:
I/O exception while talking to the server, java.io.EOFException))
####<Jun 17, 2004 8:14:17 AM MDT> <Warning> <JDBC> <EDWARDS> <edwards-s1> <ExecuteThread:
'8' for queue: 'default'> <kernel identity> <> <001094> <A connection from pool
"sp_connection_pool" was tested during reserve with the SQL "select 1" and failed:
weblogic.jdbc.mssqlserver4.TdsException: I/O exception while talking to the server,
java.io.EOFException
...[stack trace omitted]...
This connection will now be refreshed.>Brad Swanson wrote:
According to BEA's documentation, the jDriver is deprecated (no longer supported)
in WLS 7 SP5. Not sure when they stopped supporting it, but sometime after SP2,
apparently. Our solution, unfortunately, was to stay with SP2. Using the newer,
supported JDBC driver would presumably fix the problem, but we didn't have time
to do a full regression test with a different driver.Hi, no. The jDriver is deprecated, not unsupported. For WLS releases that contain
the jDriver it will be supported for as long as we support the WLS release!
Deprecation just means that we may choose to not supply that driver in any future
release, and will not support it in that or any subsequent release.
Practically, much depends on which jDriver you're using. In decreasing order
of practical support we have: The weblogic.jdbc.oci.Driver to Oracle: We do actively
continue to fix bugs in it. The weblogic.jdbc.mssqlserver4.Driver: Very unlikely that
we will fix any new problem with it. The weblogic.jdbc.ifmx.Driver: Even less
likely that we will do anything with it...
I hope that makes it better for you.
Joe -
Set Transaction timeout in Jdeveloper
hi,
I am using Jdeveloper 11.1.1.5 with JPA2.0. Is there an option where i can set the JTA Timeout for the integrated WLS server.
I know how to do it using the Web Console, however Id like to be able to do it either from a Jdeveloper setting or maybe a configuration file.
Any help is much appreciated.
Thankswhat is Transaction timeout in ATGTransaction timeout is related to application server. For more detail see below urls:
http://docs.oracle.com/cd/E36434_01/Platform.10-1-2/ATGEndecaIntegrationGuide/html/s0106increasingthetransactiontimeouta01.html
http://docs.oracle.com/cd/E24152_01/Platform.10-1/ATGInstallGuide/html/s0406settingthetransactiontimeoutonwe01.html
http://docs.oracle.com/cd/E24152_01/Platform.10-1/ATGInstallGuide/html/s0406settingthetransactiontimeoutonjb01.html
-RMishra
Edited by: RMishra on Mar 14, 2013 5:53 PM
Edited by: RMishra on Mar 14, 2013 6:10 PM -
Wls 10.3 weblogic-webservices.xml transaction-timeout attribute not working
Hi, need some urgent need.
I have a stateless ejb webservice and I'm trying to set the transaction timeout for some of the methods. Right now my webservice transaction is timing out to the default of 30 secs. I've tried setting in the admin console the JTA transaction timeout option, didn't work (file a case with bea support #81233). And after days of researching and searching I came across that you can setup the weblogic webservice transaction-timeout thru the weblogic-webservices.xml deployment descriptor. Tried setting the transaction-timeout attribute to 120 secs. and that didn't work. Here is the snippet of the xml file.
<?xml version='1.0' encoding='UTF-8'?>
<weblogic-webservices xmlns="http://www.bea.com/ns/weblogic/weblogic-webservices" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.bea.com/ns/weblogic/weblogic-webservices http://www.bea.com/ns/weblogic/weblogic-webservices/1.0/weblogic-webservices.xsd">
<webservice-description>
<webservice-description-name>com.starcomsoft.pp.system.jws.SystemWSImpl</webservice-description-name>
<webservice-type>JAXRPC</webservice-type>
<port-component>
<port-component-name>SystemWSSoapPort</port-component-name>
<service-endpoint-address>
<webservice-contextpath>starcomsoft_ws</webservice-contextpath>
<webservice-serviceuri>/SystemWSImpl</webservice-serviceuri>
</service-endpoint-address>
<transaction-timeout>120</transaction-timeout>
<reliability-config>
<inactivity-timeout>P0DT600S</inactivity-timeout>
</reliability-config>
</port-component>
</webservice-description>
</weblogic-webservice>
Does anybody have any clue to solve my urgent need.
Thanks in advance for your help or suggestion.Unhandled exception
Type=Segmentation error vmState=0x00040000
J9Generic_Signal_Number=00000004 Signal_Number=0000000b Error_Value=00000000 Signal_Code=00000033
Handler1=F144C588 Handler2=F1446A9C
Module=/app/oracle/product/Middleware/wlserver_10.3/server/native/aix/ppc/libmuxer.so
Module_base_address=D8457000
Target=2_40_20091214_049398 (AIX 5.3)
CPU=ppc (4 logical CPUs) (0x600000000 RAM)
----------- Stack Backtrace -----------
(0xD696E748 [libj9vm24.so+0x48748])
(0xD8383EDC [libjclscar_24.so+0x10edc])
(0xD8384514 [libjclscar_24.so+0x11514])
(0xD6967718 [libj9vm24.so+0x41718])
(0xD6967158 [libj9vm24.so+0x41158])
(0xD69640D0 [libj9vm24.so+0x3e0d0])
(0xD6932C9C [libj9vm24.so+0xcc9c])
(0xD69BBA18 [libj9prt24.so+0x3a18])
(0xD6932BB8 [libj9vm24.so+0xcbb8])
(0xD69A77CC [libj9thr24.so+0x27cc])
pthreadbody+0x118 (0xD010D784 [libpthreads.a+0x3784]) -
I am doing some testing to reproduce a production scenario where we ended up with messages stuck in JMS queue in receive state ( weblogic 10.3.3)...
The flow is as below:
JMS Queue --> Transactional MDB with resource reference
The MDB makes a callout to http service . No read time out configured for the http invocation
Transaction Timeout : 10 minutes for the MDB
I put a Thread.sleep in the target http service for 11 minutes
Tested by placing a message in the queue. MDB picked the message and made http call. Message substate was receive-transaction. Queue had redelivery delay of 55 seconds and redelivery limit of -1.
I would like to know what is the designed behaviour in this scenario when transaction timeout occurs at 10 minutes. ?
The behaviour I observed,
From JTA Monitoring ,At 602nd second, transaction was marked for rolled back, though the MDB code was executing [ I think this is the correct behaviuor]
Message substate was receieve-transaction till end of 660th second, when it got redelivered. Redelivery count increased by 1. I was expecting message substate to change to delayed, but it didn't,. New substate after 660th second was also receive transaction. In JTA monitoring I could also see a new transaction spawning up.
The whole purpose of my experiment was to reproduce the scenrio we are observing messages in 'receive' state when http service goes out. Any suggestion how i can get this, all I could get is receive transaction.
Thanks In Advance.So if the delay is set to 11 minutes, but the message is trapped in a receive transaction that times out after 10 minutes, there will only be a 1 minute redelivery delay... Thanks Tom. This is eaxctly the behaviour I am observing. And if redelivery delay is less than transaction timeout period, message is redelivered instantaneously when the transaction timeout occurs.
It seems you're looking into the final details of the "redelivery delay" feature's behavior? I am looking at how to trap the message in receive state. We are seeing messages stuck in receive state in production when http service goes out and it occurs randomly. My guess is since we have not configured http read time out, the socket timeout occurs at a time beyond transaction timeout and some of the complex underlying behaviours at transaction timeout event is the reason for this [ could even be a bug when dealing with this abnormal condition].
A solution for this is to set out the http read time out less than transaction timeout. We have done this in prod now and since we cant reproduce the issue , we dont know whether it fixes the problem. We are now waiting to see if the issue reoccurs . The customer doesn't like this and wants us to reproduce the issue for confirmation.
I am looking at the message substate transitions. I know for transactional weblogic MDB's and non UOO messages, the state transition will be :
Visible --> receive --> receive transaction --> transaction committed or rolled back
In this transition , it is possible for messge in receive transaction to revert back to receive status ?
P.S. we have spent huge amount of time and effort with Oracle support with no real solutions. They want us to tell them the method to reproduce the issue. -
Transaction timeout when two system communicate by web service.
Currently, our application run under WLS 10, and exchange data with another system build on WLS 10 also by web service.
These two system both set global transaction timeout through Console: Server-->Configuration-->JTA-->Timeout Seconds, set number is 1800s.
Long time operation within one system is ok, never meet tracation timeout exception. But, when one system call another system via web service, always meet below exception(same operation run under wls 8.1 is ok):
15-02-2008@17:35:56 ERROR leave : [[ACTIVE] ExecuteThread: '6' for queue: 'weblogic.kernel.Default (self-tuning)'] [CTLeaveWebService@PSA] [B2E_CTLeave.Get_Leave_Info] Exception Occured, Failure creating new instance of RowMapper, org.apache.beehive.controls.api.ControlException: RowToObjectMapper: SQLException: Unexpected exception while enlisting XAConnection java.sql.SQLException: Transaction rolled back: Transaction timed out after 30 seconds
BEA1-067F39AED8C5E04484B3
at weblogic.jdbc.jta.DataSource.enlist(DataSource.java:1419)
at weblogic.jdbc.jta.DataSource.refreshXAConnAndEnlist(DataSource.java:1331)
at weblogic.jdbc.wrapper.JTAConnection.getXAConn(JTAConnection.java:189)
at weblogic.jdbc.wrapper.JTAConnection.checkConnection(JTAConnection.java:64)
at weblogic.jdbc.wrapper.ResultSetMetaData.preInvocationHandler(ResultSetMetaData.java:37)
at weblogic.jdbc.wrapper.ResultSetMetaData_oracle_jdbc_driver_OracleResultSetMetaData.getColumnCount(Unknown Source)
at org.apache.beehive.controls.system.jdbc.RowToObjectMapper.<init>(RowToObjectMapper.java:63)
at sun.reflect.GeneratedConstructorAccessor136.newInstance(Unknown Source)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
at java.lang.reflect.Constructor.newInstance(Constructor.java:494)
at org.apache.beehive.controls.system.jdbc.RowMapperFactory.getMapper(RowMapperFactory.java:160)
at org.apache.beehive.controls.system.jdbc.RowMapperFactory.getRowMapper(RowMapperFactory.java:85)
at org.apache.beehive.controls.system.jdbc.DefaultObjectResultSetMapper.arrayFromResultSet(DefaultObjectResultSetMapper.java:93)
at org.apache.beehive.controls.system.jdbc.DefaultObjectResultSetMapper.mapToResultType(DefaultObjectResultSetMapper.java:61)
at org.apache.beehive.controls.system.jdbc.JdbcControlImpl.execPreparedStatement(JdbcControlImpl.java:370)
at org.apache.beehive.controls.system.jdbc.JdbcControlImpl.invoke(JdbcControlImpl.java:228)
at com.psa.citos.rms.leave.services.resouces.StaffLeaveDBBean.getLeaveDetailsByLvEmpIdStDtEndDtStatusInArray(StaffLeaveDBBean.java:198)
at com.psa.citos.rms.leave.services.bizlogic.StaffLeaveServiceImpl.getLeaveDetailsByLvEmpIdStDtEndDt(StaffLeaveServiceImpl.java:276)
at com.psa.citos.rms.leave.services.bizlogic.StaffLeaveServiceBean.getLeaveDetailsByLvEmpIdStDtEndDt(StaffLeaveServiceBean.java:1112)
at com.psa.citos.rms.leave.services.bizlogic.LeaveServiceImpl.getLeaveDetailsByLvEmpIdStDtEndDt(LeaveServiceImpl.java:337)
at com.psa.citos.rms.leave.services.bizlogic.LeaveServiceBean.getLeaveDetailsByLvEmpIdStDtEndDt(LeaveServiceBean.java:596)
at com.psa.citos.rms.leave.facades.WebServiceFacadesImpl.getStaffLeaveInfoForRoster(WebServiceFacadesImpl.java:254)
at com.psa.citos.rms.leave.facades.WebServiceFacadesBean.getStaffLeaveInfoForRoster(WebServiceFacadesBean.java:250)
at com.psa.citos.rms.leave.webservice.CTLeaveWebService.getLeaveInfo(Unknown Source)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at weblogic.wsee.component.pojo.JavaClassComponent.invoke(JavaClassComponent.java:99)
at weblogic.wsee.ws.dispatch.server.ComponentHandler.handleRequest(ComponentHandler.java:64)
at weblogic.wsee.handler.HandlerIterator.handleRequest(HandlerIterator.java:123)
at weblogic.wsee.ws.dispatch.server.ServerDispatcher.dispatch(ServerDispatcher.java:85)
at weblogic.wsee.ws.WsSkel.invoke(WsSkel.java:80)
at weblogic.wsee.server.servlet.SoapProcessor.handlePost(SoapProcessor.java:66)
at weblogic.wsee.server.servlet.SoapProcessor.process(SoapProcessor.java:44)
at weblogic.wsee.server.servlet.BaseWSServlet$AuthorizedInvoke.run(BaseWSServlet.java:257)
at weblogic.wsee.server.servlet.BaseWSServlet.service(BaseWSServlet.java:156)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:820)
at weblogic.servlet.internal.StubSecurityHelper$ServletServiceAction.run(StubSecurityHelper.java:226)
at weblogic.servlet.internal.StubSecurityHelper.invokeServlet(StubSecurityHelper.java:124)
at weblogic.servlet.internal.ServletStubImpl.execute(ServletStubImpl.java:283)
at weblogic.servlet.internal.ServletStubImpl.execute(ServletStubImpl.java:175)
at weblogic.servlet.internal.WebAppServletContext$ServletInvocationAction.run(WebAppServletContext.java:3392)
at weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubject.java:321)
at weblogic.security.service.SecurityManager.runAs(Unknown Source)
at weblogic.servlet.internal.WebAppServletContext.securedExecute(WebAppServletContext.java:2140)
at weblogic.servlet.internal.WebAppServletContext.execute(WebAppServletContext.java:2046)
at weblogic.servlet.internal.ServletRequestImpl.run(ServletRequestImpl.java:1366)
at weblogic.work.ExecuteThread.execute(ExecuteThread.java:200)
at weblogic.work.ExecuteThread.run(ExecuteThread.java:172)
[java.sql.SQLException: Unexpected exception while enlisting XAConnection java.sql.SQLException: Transaction rolled back: Transaction timed out after 30 seconds
Data Sourse config:
URL: jdbc:oracle:thin:@xxxxxx:1521:xxxxxx
Driver Class Name: oracle.jdbc.xa.client.OracleXADataSource
Can help to advise what this exception cause and how to resolve?
thanks and best regards.
Edited by rendlut at 02/17/2008 7:29 PM
Edited by rendlut at 02/17/2008 7:38 PMr c wrote:
> Currently, our application run under WLS 10, and exchange data with another system build on WLS 10 also by web service.
> These two system both set global transaction timeout through Console: Server-->Configuration-->JTA-->Timeout Seconds, set number is 1800s.
>
> Long time operation within one system is ok, never meet tracation timeout exception. But, when one system call another system via web service, always meet below exception(same operation run under wls 8.1 is ok):
>
> 15-02-2008@17:35:56 ERROR leave : [[ACTIVE] ExecuteThread: '6' for queue: 'weblogic.kernel.Default (self-tuning)'] [CTLeaveWebService@PSA] [B2E_CTLeave.Get_Leave_Info] Exception Occured, Failure creating new instance of RowMapper, org.apache.beehive.controls.api.ControlException: RowToObjectMapper: SQLException: Unexpected exception while enlisting XAConnection java.sql.SQLException: Transaction rolled back: Transaction timed out after 30 seconds
> BEA1-067F39AED8C5E04484B3
> at weblogic.jdbc.jta.DataSource.enlist(DataSource.java:1419)
> at weblogic.jdbc.jta.DataSource.refreshXAConnAndEnlist(DataSource.java:1331)
> at weblogic.jdbc.wrapper.JTAConnection.getXAConn(JTAConnection.java:189)
> at weblogic.jdbc.wrapper.JTAConnection.checkConnection(JTAConnection.java:64)
> at weblogic.jdbc.wrapper.ResultSetMetaData.preInvocationHandler(ResultSetMetaData.java:37)
> at weblogic.jdbc.wrapper.ResultSetMetaData_oracle_jdbc_driver_OracleResultSetMetaData.getColumnCount(Unknown Source)
> at org.apache.beehive.controls.system.jdbc.RowToObjectMapper.<init>(RowToObjectMapper.java:63)
> at sun.reflect.GeneratedConstructorAccessor136.newInstance(Unknown Source)
> at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
> at java.lang.reflect.Constructor.newInstance(Constructor.java:494)
> at org.apache.beehive.controls.system.jdbc.RowMapperFactory.getMapper(RowMapperFactory.java:160)
> at org.apache.beehive.controls.system.jdbc.RowMapperFactory.getRowMapper(RowMapperFactory.java:85)
> at org.apache.beehive.controls.system.jdbc.DefaultObjectResultSetMapper.arrayFromResultSet(DefaultObjectResultSetMapper.java:93)
> at org.apache.beehive.controls.system.jdbc.DefaultObjectResultSetMapper.mapToResultType(DefaultObjectResultSetMapper.java:61)
> at org.apache.beehive.controls.system.jdbc.JdbcControlImpl.execPreparedStatement(JdbcControlImpl.java:370)
> at org.apache.beehive.controls.system.jdbc.JdbcControlImpl.invoke(JdbcControlImpl.java:228)
> at com.psa.citos.rms.leave.services.resouces.StaffLeaveDBBean.getLeaveDetailsByLvEmpIdStDtEndDtStatusInArray(StaffLeaveDBBean.java:198)
> at com.psa.citos.rms.leave.services.bizlogic.StaffLeaveServiceImpl.getLeaveDetailsByLvEmpIdStDtEndDt(StaffLeaveServiceImpl.java:276)
> at com.psa.citos.rms.leave.services.bizlogic.StaffLeaveServiceBean.getLeaveDetailsByLvEmpIdStDtEndDt(StaffLeaveServiceBean.java:1112)
> at com.psa.citos.rms.leave.services.bizlogic.LeaveServiceImpl.getLeaveDetailsByLvEmpIdStDtEndDt(LeaveServiceImpl.java:337)
> at com.psa.citos.rms.leave.services.bizlogic.LeaveServiceBean.getLeaveDetailsByLvEmpIdStDtEndDt(LeaveServiceBean.java:596)
> at com.psa.citos.rms.leave.facades.WebServiceFacadesImpl.getStaffLeaveInfoForRoster(WebServiceFacadesImpl.java:254)
> at com.psa.citos.rms.leave.facades.WebServiceFacadesBean.getStaffLeaveInfoForRoster(WebServiceFacadesBean.java:250)
> at com.psa.citos.rms.leave.webservice.CTLeaveWebService.getLeaveInfo(Unknown Source)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:585)
> at weblogic.wsee.component.pojo.JavaClassComponent.invoke(JavaClassComponent.java:99)
> at weblogic.wsee.ws.dispatch.server.ComponentHandler.handleRequest(ComponentHandler.java:64)
> at weblogic.wsee.handler.HandlerIterator.handleRequest(HandlerIterator.java:123)
> at weblogic.wsee.ws.dispatch.server.ServerDispatcher.dispatch(ServerDispatcher.java:85)
> at weblogic.wsee.ws.WsSkel.invoke(WsSkel.java:80)
> at weblogic.wsee.server.servlet.SoapProcessor.handlePost(SoapProcessor.java:66)
> at weblogic.wsee.server.servlet.SoapProcessor.process(SoapProcessor.java:44)
> at weblogic.wsee.server.servlet.BaseWSServlet$AuthorizedInvoke.run(BaseWSServlet.java:257)
> at weblogic.wsee.server.servlet.BaseWSServlet.service(BaseWSServlet.java:156)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:820)
> at weblogic.servlet.internal.StubSecurityHelper$ServletServiceAction.run(StubSecurityHelper.java:226)
> at weblogic.servlet.internal.StubSecurityHelper.invokeServlet(StubSecurityHelper.java:124)
> at weblogic.servlet.internal.ServletStubImpl.execute(ServletStubImpl.java:283)
> at weblogic.servlet.internal.ServletStubImpl.execute(ServletStubImpl.java:175)
> at weblogic.servlet.internal.WebAppServletContext$ServletInvocationAction.run(WebAppServletContext.java:3392)
> at weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubject.java:321)
> at weblogic.security.service.SecurityManager.runAs(Unknown Source)
> at weblogic.servlet.internal.WebAppServletContext.securedExecute(WebAppServletContext.java:2140)
> at weblogic.servlet.internal.WebAppServletContext.execute(WebAppServletContext.java:2046)
> at weblogic.servlet.internal.ServletRequestImpl.run(ServletRequestImpl.java:1366)
> at weblogic.work.ExecuteThread.execute(ExecuteThread.java:200)
> at weblogic.work.ExecuteThread.run(ExecuteThread.java:172)
> [java.sql.SQLException: Unexpected exception while enlisting XAConnection java.sql.SQLException: Transaction rolled back: Transaction timed out after 30 seconds
>
> Data Sourse config:
> URL: jdbc:oracle:thin:@xxxxxx:1521:xxxxxx
> Driver Class Name: oracle.jdbc.xa.client.OracleXADataSource
>
>
> Can help to advise what this exception cause and how to resolve?
>
> thanks and best regards.
>
> --
> Edited by rendlut at 02/17/2008 7:29 PM
>
> --
> Edited by rendlut at 02/17/2008 7:38 PM
In the console, you can set the JTA timeout to
something more appropriate for your needs than
the default 30 seconds.
Joe -
Changing default transaction timeout for 5.1
Hi
Does someone know a way to change the default ejb transaction timeout for
WL5.1?
The default is 300 secs, which is a bit too long for me.
I know I can change it in each deployment descriptor but it would be easier
and quicker if I could just change the default :-)
Thanks
Nicolas
There is another way but I think it's more complicated.
After reading the file you can use a java code (java embedded activity) and split the file.
For each part of the split you can PUT by FTP the file with append mode. That way your transaction will run in few cycles with less time.
Maybe you are looking for
-
Local characters in Name and Address Details
Hi, For an Thailand Employee, I need to print his Name from PA0182(Alternative Names) and the Adress Details from Pa0006 with a custom subtype 0026(Thailand Address). The source of Name and Address is different if I want to do the same for a Taiwan P
-
Cost of Sales activation in Controlling area
Hi Friends, Please let me know the IMG activity where we can check if 'Cost of sales accounting' is active in a controlling area or not. Please help me navigate. Thanks & regards, Shilpi
-
[SOLVED] - X won't start - Missing modules??
Hello all, thanks for looking. I have installed from the Arch from the latest media, and followed the Begginers Guide. I have installed to a partition on my hard disk, one of many, and installed Grub and the mbr. The system boots fine. ALSA works, Xo
-
Edit from aperture to photoshop
When I edit my photos from aperture 3 to photoshop it transfers from a raw file to a tiff file. Is there an easy way to transfer a raw file from aperture to Photoshop and maintain it as a raw file. I presently have to export the raw file from apertur
-
How do I get all my photos and conversations that I have on my iPhone to my iPad?