Marking the transaction as rollback in JPD

I have a stateless JPD (with Client Request with Return as the start node).
If an exception is thrown anywhere in the JPD and "remains" unhandled the transaction
rollbacks automatically - which is desired. However any piece that happens as
a result is that the Process is marked as "Aborted" (on the WLI admin console)
and the client gets a runtime unhandled exception (SOAP Fault)- which is not wan't
I wan't to return to the client as a JPD developer.
So I am stuck as I wan't the transaction to rollback but at the same time I wan't
to send a more user friendly response (say an XML contract) with the error details....
I am using WLI 8.1 SP2.
BEA folks - please speak up ... Do you guys have any inside info. that you could
please share or point to!
Thanks very much

Hi Ric,
Thanks for your input. Although this document has aided my undertanding of state management and connection pooling, I am still none the wiser as to why I am experiencing this issue.
On closer inspection I have found that the doDML(int, TransactionEvent) is not being called until I insert a row.
So if I query my master VO, set the first row to current, update an attribute on a detail row then postChanges on the transaction, doDML does not get called.
If I insert a row into my detail VO then postChanges on the transaction, it calls doDML issuing the original update I entered in the above step.
It seems I have a similar problem to the that described in the following thread but there seems to be no outcome.
Re: doDML() not called at postChanges?
In my desparation, I am tempted to just insert a row and then remove it just to put the EO's in the correct state if the user updates a row before inserting a new one.
Any help would be greatly appreciated.
Thanks.

Similar Messages

Error marking transaction for rollback: java.lang.IllegalStateException in WLI 6.1 SP3

Hi,
The following exception occurs, when the workflow was waiting after it has made
a synchronous call to an external system through WTC Interface.
I had read Rob's comments earlier for WLI 6.1 SP1 on this exception that there
would be a fix available for it in the next minor release. For your information,
I had got this exception in WLI 6.1 SP3. Is still EJB Container's timeout excels
the JTA's timeout? Can anybody help me out to find a fix for this problem?
Thanks in Advance,
Regards
Jegadeesan.
The Stack Trace is given below :
<Error marking transaction for rollback: java.lang.IllegalStateException: Cannot
mark the transaction for rollback. xid=4362:5b4c62b47adcc632, status=Rolled back.
[Reason=weblogic.transaction.internal.TimedOutException: Transaction timed out
after 31 seconds
Xid=4362:5b4c62b47adcc632(6932052),Status=Active,numRepliesOwedMe=0,numRepliesOwedOthers=0,seconds
since begin=31,seconds left=30,ServerResourceInfo[weblogic.jdbc.jts.Connection]=(state=ended,assigned=none),SCInfo[ecwli001+admin_ecwli001]=(state=active),properties=({weblogic.jdbc=t3://147.149.116.70:50101}),OwnerTransactionManager=ServerTM[ServerCoordinatorDescriptor=(CoordinatorURL=admin_ecwli001+147.149.116.70:50101+ecwli001+,
Resources={})],CoordinatorURL=admin_ecwli001+147.149.116.70:50101+ecwli001+)]>
java.lang.IllegalStateException: Cannot mark the transaction for rollback. xid=4362:5b4c62b47adcc632,
status=Rolled back. [Reason=weblogic.transaction.internal.TimedOutException: Transaction
timed out after 31 seconds
Xid=4362:5b4c62b47adcc632(6932052),Status=Active,numRepliesOwedMe=0,numRepliesOwedOthers=0,seconds
since begin=31,seconds left=30,ServerResourceInfo[weblogic.jdbc.jts.Connection]=(state=ended,assigned=none),SCInfo[ecwli001+admin_ecwli001]=(state=active),properties=({weblogic.jdbc=t3://147.149.116.70:50101}),OwnerTransactionManager=ServerTM[ServerCoordinatorDescriptor=(CoordinatorURL=admin_ecwli001+147.149.116.70:50101+ecwli001+,
Resources={})],CoordinatorURL=admin_ecwli001+147.149.116.70:50101+ecwli001+)]
     at weblogic.transaction.internal.TransactionImpl.throwIllegalStateException(TransactionImpl.java:1492)
     at weblogic.transaction.internal.TransactionImpl.setRollbackOnly(TransactionImpl.java:466)
     at weblogic.ejb20.manager.BaseEJBManager.handleSystemException(BaseEJBManager.java:255)
     at weblogic.ejb20.manager.BaseEJBManager.setupTxListener(BaseEJBManager.java:215)
     at weblogic.ejb20.manager.StatelessManager.preInvoke(StatelessManager.java:153)
     at weblogic.ejb20.internal.BaseEJBObject.preInvoke(BaseEJBObject.java:124)
     at weblogic.ejb20.internal.StatelessEJBObject.preInvoke(StatelessEJBObject.java:63)
     at com.bea.wlpi.server.principal.WLPIPrincipalBean_u7lmf4_EOImpl.getOrganizationInfo(WLPIPrincipalBean_u7lmf4_EOImpl.java:463)
     at com.bea.wlpi.server.workflowprocessor.WorkflowProcessorBean.getBusinessCalendarProcessor(Unknown
Source)
     at com.bea.wlpi.server.workflow.Timer.dateAdd(Unknown Source)
     at com.bea.wlpi.server.workflow.action.ActionTimedEvent.getScheduleTimestamp(Unknown
Source)
     at com.bea.wlpi.server.workflow.action.ActionTimedEvent.execute(Unknown Source)
     at com.bea.wlpi.server.workflowprocessor.WorkflowProcessorBean.executeActions(Unknown
Source)
     at com.bea.wlpi.server.workflow.Task.executeActions(Unknown Source)
     at com.bea.wlpi.server.workflow.Task.activate(Unknown Source)
     at com.bea.wlpi.server.workflowprocessor.WorkflowProcessorBean.activateSuccessors(Unknown
Source)
     at com.bea.wlpi.server.workflow.Decision.activate(Unknown Source)
     at com.bea.wlpi.server.workflowprocessor.WorkflowProcessorBean.activateSuccessors(Unknown
Source)
     at com.bea.wlpi.server.workflow.Decision.activate(Unknown Source)
     at com.bea.wlpi.server.workflowprocessor.WorkflowProcessorBean.activateSuccessors(Unknown
Source)
     at com.bea.wlpi.server.workflow.Task.markDone(Unknown Source)
     at com.bea.wlpi.server.workflow.action.ActionTaskDone.execute(Unknown Source)
     at com.bea.wlpi.server.workflowprocessor.WorkflowProcessorBean.executeActions(Unknown
Source)
     at com.bea.wlpi.server.workflow.Task.executeActions(Unknown Source)
     at com.bea.wlpi.server.workflow.Task.activate(Unknown Source)
     at com.bea.wlpi.server.workflowprocessor.WorkflowProcessorBean.activateSuccessors(Unknown
Source)
     at com.bea.wlpi.server.workflow.Task.markDone(Unknown Source)
     at com.bea.wlpi.server.workflow.action.ActionTaskDone.execute(Unknown Source)
     at com.bea.wlpi.server.workflowprocessor.WorkflowProcessorBean.executeActions(Unknown
Source)
     at com.bea.wlpi.server.workflow.Task.executeActions(Unknown Source)
     at com.bea.wlpi.server.workflow.Task.activate(Unknown Source)
     at com.bea.wlpi.server.workflowprocessor.WorkflowProcessorBean.activateSuccessors(Unknown
Source)
     at com.bea.wlpi.server.workflow.Task.markDone(Unknown Source)
     at com.bea.wlpi.server.workflow.action.ActionTaskDone.execute(Unknown Source)
     at com.bea.wlpi.server.workflowprocessor.WorkflowProcessorBean.executeActions(Unknown
Source)
     at com.bea.wlpi.server.workflow.Task.executeActions(Unknown Source)
     at com.bea.wlpi.server.workflow.Task.activate(Unknown Source)
     at com.bea.wlpi.server.workflowprocessor.WorkflowProcessorBean.activateSuccessors(Unknown
Source)
     at com.bea.wlpi.server.workflow.Task.markDone(Unknown Source)
     at com.bea.wlpi.server.workflow.action.ActionTaskDone.execute(Unknown Source)
     at com.bea.wlpi.server.workflowprocessor.WorkflowProcessorBean.executeActions(Unknown
Source)
     at com.bea.wlpi.server.workflow.Task.executeActions(Unknown Source)
     at com.bea.wlpi.server.workflow.Task.activate(Unknown Source)
     at com.bea.wlpi.server.workflowprocessor.WorkflowProcessorBean.activateSuccessors(Unknown
Source)
     at com.bea.wlpi.server.workflow.Start.activate(Unknown Source)
     at com.bea.wlpi.server.workflow.Workflow.start(Unknown Source)
     at com.bea.wlpi.server.workflow.Workflow.instantiate(Unknown Source)
     at com.bea.wlpi.server.workflowprocessor.WorkflowProcessorBean$1.invoke(Unknown
Source)
     at com.bea.wlpi.server.workflowprocessor.WorkflowProcessorBean.performWithErrorHandling(Unknown
Source)
     at com.bea.wlpi.server.workflowprocessor.WorkflowProcessorBean.instantiate(Unknown
Source)
     at com.bea.wlpi.server.workflowprocessor.WorkflowProcessorBean_h7kt4j_EOImpl.instantiate(WorkflowProcessorBean_h7kt4j_EOImpl.java:692)
     at com.bea.wlpi.server.eventprocessor.EventProcessor.checkTrigger(Unknown Source)
     at com.bea.wlpi.server.eventprocessor.EventProcessor.onEvent(Unknown Source)
     at com.bea.wlpi.server.eventlistener.EventListenerBean.onMessage(Unknown Source)
     at weblogic.ejb20.internal.MDListener.execute(MDListener.java:262)
     at weblogic.ejb20.internal.MDListener.onMessage(MDListener.java:214)
     at weblogic.jms.client.JMSSession.onMessage(JMSSession.java:1865)
     at weblogic.jms.client.JMSSession.execute(JMSSession.java:1819)
     at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:139)
     at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:120)

You could change the transaction timeout value, but I'd re-examine the
application and see if the transaction times could be reduced some.
29 seconds seems like a long time.

Rolling back the transaction from stateful session bean

Hi,
How can I mark the transaction to be rolled back in a stateful session bean implementation?.
Should I call setRollbackOnly method or throw a RemoteException or throw an EJBException, etc.?
the configuration is :
OC4J 9.0.4
Stateful session bean
Related method has transaction attribute - "Required"
thanks & regards.
ps : I couldn't find a related topic even if this has been discussed before (too many topics). if so, excuses.
Erdem.

Tried using Bean managed transactions but with the same result. Given below is the sample code.
UserTransaction uts = null;
try {
uts = (UserTransaction)(ctx.getUserTransaction());
uts.begin();
Connection con = null;
con = getCountConnection();
PreparedStatement ps = con.prepareStatement(sqlselectUserId);
ps.executeUpdate();
PreparedStatement ps1 = con.prepareStatement(sqlselectUserDetails);
ps1.executeUpdate();
uts.commit();
catch(SQLException e) {
uts.rollback();

File Adapter Exception 'The transaction is marked for rollback.'

Hi, folks!
I have sometimes a problem with different FileAdapters. They throw the following exception...
com.sap.engine.services.ejb.exceptions.BaseTransactionRolledbackLocalException: Exception thrown in method process. The transaction is marked for rollback.
The only thing that helps is to restart the AdapterEngine.
Could someone please help me?
Thanks
Thomas

Thomas
There was a similar problem here:
Re: StringBuffer problems in custom Adapter Modules
Not sure if that may help!

Errors using weblogic sql driver: "No JDBC connection can be made because the transaction state is marked rollback"

One of our customers starts to encounter this error message recently.
We checked our log files. It seems that the error happens when
to obtain a jdbc connection. Have anyone seen similar problems
and knows how to fix it? thanks in advance.
We are using weblogic server 6.1sp2, and weblogic sql type 4 driver.
The functions that invoke the jdbc calls are stateless session bean
methods with their transaction attributes marked as Required.
There is no nested calls of these methods.
A partial stack trace we obtained is as following:
java.sql.SQLException: No JDBC connection can be made
because the transaction state is
Marked Rollback
     at weblogic.jdbc.jts.Connection.getOrCreateConnection(Connection.java:586)
     at weblogic.jdbc.jts.Connection.prepareStatement(Connection.java:115)
     at weblogic.jdbc.rmi.internal.ConnectionImpl.prepareStatement(ConnectionImpl.java:135)
     at weblogic.jdbc.rmi.SerialConnection.prepareStatement(SerialConnection.java:76)
lixin

Joseph Weinstein <[email protected]> wrote:
>
>
YuanHui Liu wrote:
Joe,
We got the exact same error message. The error came after we got theJDBC connection,
and trying to create statement off it.
It occurs intermitently when we are running another standalone JAVAapp to do
some end of day work, which results in the DB Server being very busy(90+%CPU
usage) for about 5 minutes. We see a surge of requests to the WLSJDBC Connection
pool. This would sometimes result in all our subsequent DB requeststo fail and
lead to a crash.
We are using WLS6.0SP1. I do not think there's a 30 seconds wait leadingto a
connection timeout that caused this(rather it is the end effect).
Can you give us a more detailed explanation? Is there a miscommunicationbetween
our DB(Sybase12) and WLS?Hi. It looks to you like it's after you get the connection, but really
it's when the server is
gettng the pool connection. For performance/synchronization reasons we
do a clever
delay: When your code asks for a pool connection we quickly give you
the pool wrapper,
but we delay actually reserving the real underlying DBMS connection until
your first
real need for a connection, at your first JDBC call, such as createStatement()
etc.
It is while waiting for a pool connection long enough for the transaction
coordinator
to have timed you out before you ever get a chance. It's nothing to do
with the
DBMS or even JDBC, I believe. I think the weblogic server either has
too few execute-threads
and/or too few CPU cycles to do the work load.
Okay, so there's a lazy initialization of the connection.
From reading our log I believe our failur is immediate rather
than waiting for 30+ seconds(the default setting) from the DB,
the timeout occurred later as a result. At the time either because the DB Server
is very busy.
Since we are running WLS6.0 we have only one connection pool,
we have defined a max of 150 threads in the pool. While this
is happening the DB Server is being pinned by an overnight job,
but the WLS Server is not busy at all. The DB and WLS resides
on different physical boxes.
We also have a thread dump from the WLS console when we rebooted the server, it
showed that we are hanging on to the thread & jdbc
connections after these exceptions has occurred instead of releasing them, note
"16083"(~4.5 hours) seconds has passed:
142 116222 Retry rollback request for tx: 'transaction=(IdHash=2963855,Name =
[EJB UserManagerBeanImpl.signalICUserServletHeartBeat()],Xid=30643:8f3838f3709bf53d,Status=Rolling
Back. [Reason = Unknown],numRepliesOwedMe=0,numRepliesOwedOthers=0,seconds since
begin=16083,seconds left=10,ServerResourceInfo[weblogic.jdbc.jts.Connection]=(state=started,assigned=server),SCInfo[server]=(state=active),properties=({weblogic.jdbc=t3://159.55.158.25:8005,
weblogic.transaction.name=[EJB UserManagerBeanImpl.signalICUserServletHeartBeat()]}))'
Scheduled Trigger
So I would argue this problem actually chewed up resources on the WLS server.
-Yuanhui Liu
>>
>>
Thanks.
-YuanHui Liu
Joseph Weinstein <[email protected]> wrote:
lixin wrote:
One of our customers starts to encounter this error message recently.
We checked our log files. It seems that the error happens when
to obtain a jdbc connection. Have anyone seen similar problems
and knows how to fix it? thanks in advance.
We are using weblogic server 6.1sp2, and weblogic sql type 4 driver.
The functions that invoke the jdbc calls are stateless session bean
methods with their transaction attributes marked as Required.
There is no nested calls of these methods.
A partial stack trace we obtained is as following:
java.sql.SQLException: No JDBC connection can be made
because the transaction state is
Marked Rollback
at weblogic.jdbc.jts.Connection.getOrCreateConnection(Connection.java:586)Hi. This sounds like a JVM thread starvation issue, and/or a server
load
issue. What is
happening is that the transaction is started, and times out beforethe
SSB even gets to
the first JDBC work. I would first verify that the customer is using
the very latest JVM
available for the machine.
Joe Weinstein
at weblogic.jdbc.jts.Connection.prepareStatement(Connection.java:115)
at weblogic.jdbc.rmi.internal.ConnectionImpl.prepareStatement(ConnectionImpl.java:135)
at weblogic.jdbc.rmi.SerialConnection.prepareStatement(SerialConnection.java:76)
lixin

SqlTransaction.Rollback() does not throw InvalidOperationException in case the transaction has already been rolled back.

According to
MSDN SqlTransaction.Rollback() method must throw InvalidOperationException in case the transaction has already been committed or rolled back.
However, in my tests I don't get any exceptions. Here is the code:
CREATE PROCEDURE dbo.USP_TEST_TX_PROC
AS
BEGIN
SELECT 1/0;
ROLLBACK TRANSACTION;
END
GO
using(SqlConnection con = new SqlConnection(@"Data Source=XXX;Initial Catalog=TestDB;Integrated Security=True"))
con.Open();
SqlTransaction tr = con.BeginTransaction();
SqlCommand cmd = new SqlCommand("dbo.USP_TEST_TX_PROC", con, tr) { CommandType = CommandType.StoredProcedure};
try
cmd.ExecuteNonQuery();
tr.Commit();
catch (Exception ex)
try
tr.Rollback();
catch (Exception ex2)
Console.WriteLine(" Message: {0}", ex2.Message);
What am I doing wrong?
Thank you.
Alexey

Hello Alexey,
I created a client side demo which could throw the InvalidOperationException:
using (SqlConnection connection = new SqlConnection(@"Server=(localdb)\Projects;Database=DFDB;Trusted_Connection=True;"))
connection.Open();
SqlCommand command = connection.CreateCommand();
SqlTransaction transaction;
transaction = connection.BeginTransaction("SampleTransaction");
command.Connection = connection;
command.Transaction = transaction;
try
command.CommandText = "ProInsertIntoOrder 1,'1'";
command.ExecuteNonQuery();
transaction.Rollback();
throw new Exception();
catch (Exception ex)
// Attempt to roll back the transaction.
try
transaction.Rollback();
catch (InvalidOperationException ex2)
Console.WriteLine("Rollback Exception Type: {0}", ex2.GetType());
Console.WriteLine(" Message: {0}", ex2.Message);
You could have a try. However, it is not clear why it could detect the ROLLBACK statement on the server side, I suggest that you could post this feedback to:
https://connect.microsoft.com/VisualStudio/feedback/LoadSubmitFeedbackForm
Regards.
We are trying to better understand customer views on social support experience, so your participation in this interview project would be greatly appreciated if you have time. Thanks for helping make community forums a great place.
Click
HERE to participate the survey.

WLS 6.1 The transaction is no longer active...

Hello guys,
I have a litle problem. We have an application deployed on WLS 5.1. It is working perfect for more than an year now. We recently migrated to WLS 6.1, which went pretty painlessly. The only problem I figured out is a transaction timeout on one of our EJBs. It's a stateless one and does access a database. The database response time seems to exceed 30 secs and the container just rolls the transaction back and raises an exception:
The transaction is no longer active (status = Marked rollback. [Reason=weblogic.transaction.internal.TimedOutException: Transaction timed out after 31 seconds
Name=[EJB com.deuba.pricemodel.sessionbean.FXRateManagerEJB.populate()],Xid=46:1c5c7ecedef996e9(6195252),Status=Active,numRepliesOwedMe=0,numRepliesOwedOthers=0,seconds since begin=31,seconds left=30,activeThread=Thread[ExecuteThread: '9' for queue: 'default',5,Thread Group for Queue: 'default'],ServerResourceInfo[weblogic.jdbc.jts.Connection]=(state=started,assigned=none),SCInfo[npm2000+npm2000_1]=(state=active),properties=({weblogic.transaction.name=[EJB com.deuba.pricemodel.sessionbean.FXRateManagerEJB.populate()], weblogic.jdbc=t3://10.72.70.17:7201}),OwnerTransactionManager=ServerTM[ServerCoordinatorDescriptor=(CoordinatorURL=npm2000_1+10.72.70.17:7201+npm2000+, Resources={})],CoordinatorURL=npm2000_1+10.72.70.17:7201+npm2000+)]). No further JDBC access is allowed within this transaction.
com.deuba.pricemodel.sessionbean.FXRateManagerEJB_9hbfr9_Impl populate rolled back. Reason: The transaction is no longer active (status = Marked rollback. [Reason=weblogic.transaction.internal.TimedOutException: Transaction timed out after 31 seconds
Name=[EJB com.deuba.pricemodel.sessionbean.FXRateManagerEJB.populate()],Xid=46:1c5c7ecedef996e9(6195252),Status=Active,numRepliesOwedMe=0,numRepliesOwedOthers=0,seconds since begin=31,seconds left=30,activeThread=Thread[ExecuteThread: '9' for queue: 'default',5,Thread Group for Queue: 'default'],ServerResourceInfo[weblogic.jdbc.jts.Connection]=(state=started,assigned=none),SCInfo[npm2000+npm2000_1]=(state=active),properties=({weblogic.transaction.name=[EJB com.deuba.pricemodel.sessionbean.FXRateManagerEJB.populate()], weblogic.jdbc=t3://10.72.70.17:7201}),OwnerTransactionManager=ServerTM[ServerCoordinatorDescriptor=(CoordinatorURL=npm2000_1+10.72.70.17:7201+npm2000+, Resources={})],CoordinatorURL=npm2000_1+10.72.70.17:7201+npm2000+)]). No further JDBC access is allowed within this transaction.
java.sql.SQLException: The transaction is no longer active (status = Marked rollback. [Reason=weblogic.transaction.internal.TimedOutException: Transaction timed out after 31 secondsName=[EJB com.deuba.pricemodel.sessionbean.FXRateManagerEJB.populate()],Xid=46:1c5c7ecedef996e9(6195252),Status=Active,numRepliesOwedMe=0,numRepliesOwedOthers=0,seconds since begin=31,seconds left=30,activeThread=Thread[ExecuteThread: '9' for queue: 'default',5,Thread Group for Queue: 'default'],ServerResourceInfo[weblogic.jdbc.jts.Connection]=(state=started,assigned=none),SCInfo[npm2000+npm2000_1]=(state=active),properties=({weblogic.transaction.name=[EJB com.deuba.pricemodel.sessionbean.FXRateManagerEJB.populate()], weblogic.jdbc=t3://10.72.70.17:7201}),OwnerTransactionManager=ServerTM[ServerCoordinatorDescriptor=(CoordinatorURL=npm2000_1+10.72.70.17:7201+npm2000+, Resources={})],CoordinatorURL=npm2000_1+10.72.70.17:7201+npm2000+)]). No further JDBC access is allowed within this transaction.
        at weblogic.jdbc.jts.Connection.checkIfRolledBack(Connection.java:508)
        at weblogic.jdbc.jts.Statement.getResultSet(Statement.java:408)
        at weblogic.jdbc.rmi.internal.StatementImpl.getResultSet(StatementImpl.java:215)
        at weblogic.jdbc.rmi.SerialStatement.getResultSet(SerialStatement.java:322)
        at com.deuba.pricemodel.pool.FXRatePool.populate(Unknown Source)
        at com.deuba.pricemodel.sessionbean.FXRateManagerEJB.populate(Unknown Source)
        at com.deuba.pricemodel.sessionbean.FXRateManagerEJB_9hbfr9_EOImpl.populate(FXRateManagerEJB_9hbfr9_EOImpl.java:121)
        at jsp_servlet._system._qa.__fx_rate._jspService(__fx_rate.java:290)
        at weblogic.servlet.jsp.JspBase.service(JspBase.java:27)
        at weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:265)
        at weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:200)
        at weblogic.servlet.internal.WebAppServletContext.invokeServlet(WebAppServletContext.java:2495)
        at weblogic.servlet.internal.ServletRequestImpl.execute(ServletRequestImpl.java:2204)
        at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:139)
        at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:120)One problem could be, that the EJBs are compiled with the WLS 5.1 ejbc and also the deployment descriptors are 5.1 compliant. Does anyone have any clue?
Tx in advance,
Anton Maleev
Software Engineer
Frankfurt
[email protected]

Take a look at this link:
http://e-docs.bea.com/wls/docs61////javadocs/weblogic/management/configuration/JTAMBean.html#getTimeoutSeconds()
You'll notice the default transaction timeout in WLS 6.1 is 30 seconds. For container managed you
can set this timeout in the trans-timeout-seconds attribute of the weblogic-ejb-xml.jar file.

The transaction is no longer active - Transaction timed out after 30 second

We have an intermittent error here, and I'm a rookie. The error results in a 500 being sent to the customer every 10th-20th POST and only occurs under heavy load. The heavy loading is over the for the day, but it'll be back.
My first suspicion was the app code doing transaction work and having database performance problems. But the app is non-transactional and the database is fine. The server farm nodes (4) are all experiencing the problems at equal rates, and the other apps on the farm are fine, so it appears to be app-specific rather than rooted in server state or database state.
I looked at the stack a little more closely and it appears to be some kind of internal persistence issue, but a completely foreign one to me. We have no Persistent Stores configured, so I don't know where to even start on this puppy.
EJB Exception occurred during invocation from home: weblogic.ejb.container.internal.StatelessEJBLocalHomeImpl@d1e1f4 threw exception: <1.0.0 nonfatal general error> org.apache.openjpa.persistence.PersistenceException: The transaction is no longer active - status: 'Marked rollback. [Reason=weblogic.transaction.internal.TimedOutException: Transaction timed out after 30 seconds
BEA1-32AE928C966AC66F424D]'. No further JDBC access is allowed within this transaction.
<1.0.0 nonfatal general error> org.apache.openjpa.persistence.PersistenceException: The transaction is no longer active - status: 'Marked rollback. [Reason=weblogic.transaction.internal.TimedOutException: Transaction timed out after 30 seconds
BEA1-32AE928C966AC66F424D]'. No further JDBC access is allowed within this transaction.
at org.apache.openjpa.jdbc.sql.DBDictionary.newStoreException(DBDictionary.java:3784)
at org.apache.openjpa.jdbc.sql.SQLExceptions.getStore(SQLExceptions.java:97)
at org.apache.openjpa.jdbc.sql.SQLExceptions.getStore(SQLExceptions.java:83)
at org.apache.openjpa.jdbc.sql.SQLExceptions.getStore(SQLExceptions.java:59)
at org.apache.openjpa.jdbc.kernel.SelectResultObjectProvider.handleCheckedException(SelectResultObjectProvider.java:155)
at org.apache.openjpa.lib.rop.EagerResultList.<init>(EagerResultList.java:40)
at org.apache.openjpa.kernel.QueryImpl.toResult(QueryImpl.java:1219)
at org.apache.openjpa.kernel.QueryImpl.execute(QueryImpl.java:987)
at org.apache.openjpa.kernel.QueryImpl.execute(QueryImpl.java:839)
at org.apache.openjpa.kernel.QueryImpl.execute(QueryImpl.java:770)
at kodo.kernel.KodoQuery.execute(KodoQuery.java:47)
at org.apache.openjpa.kernel.DelegatingQuery.execute(DelegatingQuery.java:525)
at org.apache.openjpa.persistence.QueryImpl.execute(QueryImpl.java:229)
at org.apache.openjpa.persistence.QueryImpl.getResultList(QueryImpl.java:269)
at kodo.persistence.KodoQueryImpl.getResultList(KodoQueryImpl.java:213)
at kodo.persistence.KodoQueryImpl.getResultList(KodoQueryImpl.java:213)
at com.company.buapp.buslogic.helpers.ApproveApplicationHelper.createNewTransactionsExcludingApplication(ApproveApplicationHelper.java:167)
at com.company.buapp.buslogic.helpers.ApproveApplicationHelper.createNewTransactions(ApproveApplicationHelper.java:129)
at com.company.buapp.buslogic.helpers.ApproveApplicationHelper.stageAction(ApproveApplicationHelper.java:74)
at com.company.buapp.buslogic.session.ApproveApplicationSessionBean.performAction(ApproveApplicationSessionBean.java:348)
at sun.reflect.GeneratedMethodAccessor2150.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at com.bea.core.repackaged.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:281)
at com.bea.core.repackaged.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:187)
at com.bea.core.repackaged.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:154)
at com.bea.core.repackaged.springframework.aop.support.DelegatingIntroductionInterceptor.doProceed(DelegatingIntroductionInterceptor.java:126)
at com.bea.core.repackaged.springframework.aop.support.DelegatingIntroductionInterceptor.invoke(DelegatingIntroductionInterceptor.java:114)
at com.bea.core.repackaged.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:176)
at weblogic.ejb.container.injection.EnvironmentInterceptor.invoke(EnvironmentInterceptor.java:68)
at com.bea.core.repackaged.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:176)
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:176)
at com.bea.core.repackaged.springframework.aop.support.DelegatingIntroductionInterceptor.doProceed(DelegatingIntroductionInterceptor.java:126)
at com.bea.core.repackaged.springframework.aop.support.DelegatingIntroductionInterceptor.invoke(DelegatingIntroductionInterceptor.java:114)
at com.bea.core.repackaged.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:176)
at com.bea.core.repackaged.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:210)
at $Proxy365.performAction(Unknown Source)
at com.company.buapp.buslogic.session.ApproveApplicationSessionBean_gc4fhc_ApproveApplicationSessionLocalImpl.performAction(ApproveApplicationSessionBean_gc4fhc_ApproveApplicationSessionLocalImpl.java:148)
at com.company.buapp.si.ApplicationWS.performAction(ApplicationWS.java:114)
at sun.reflect.GeneratedMethodAccessor2149.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at weblogic.wsee.jaxws.WLSInvoker.invoke(WLSInvoker.java:50)
at weblogic.wsee.jaxws.WLSInvoker.invoke(WLSInvoker.java:42)
at com.sun.xml.ws.server.sei.EndpointMethodHandler.invoke(EndpointMethodHandler.java:247)
at com.sun.xml.ws.server.sei.SEIInvokerPipe.process(SEIInvokerPipe.java:97)
at weblogic.wsee.jaxws.MonitoringPipe.process(MonitoringPipe.java:98)
at com.sun.xml.ws.protocol.soap.ServerMUPipe.process(ServerMUPipe.java:62)
at com.sun.xml.ws.server.WSEndpointImpl$1.process(WSEndpointImpl.java:139)
at com.sun.xml.ws.transport.http.HttpAdapter$HttpToolkit.handle(HttpAdapter.java:153)
at com.sun.xml.ws.transport.http.HttpAdapter.handle(HttpAdapter.java:235)
at com.sun.xml.ws.transport.http.servlet.ServletAdapter.handle(ServletAdapter.java:97)
at weblogic.wsee.jaxws.HttpServletAdapter.post(HttpServletAdapter.java:36)
at weblogic.wsee.jaxws.JAXWSServlet.doPost(JAXWSServlet.java:218)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:727)
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:3395)
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: The transaction is no longer active - status: 'Marked rollback. [Reason=weblogic.transaction.internal.TimedOutException: Transaction timed out after 30 seconds
BEA1-32AE928C966AC66F424D]'. No further JDBC access is allowed within this transaction.
at weblogic.jdbc.wrapper.JTSConnection.checkIfRolledBack(JTSConnection.java:178)
at weblogic.jdbc.wrapper.JTSConnection.checkConnection(JTSConnection.java:188)
at weblogic.jdbc.wrapper.ResultSet.preInvocationHandler(ResultSet.java:57)
at weblogic.jdbc.wrapper.ResultSet_oracle_jdbc_driver_OracleResultSetImpl.next(Unknown Source)
at org.apache.openjpa.lib.jdbc.DelegatingResultSet.next(DelegatingResultSet.java:106)
at org.apache.openjpa.jdbc.sql.ResultSetResult.nextInternal(ResultSetResult.java:210)
at org.apache.openjpa.jdbc.sql.SelectImpl$SelectResult.nextInternal(SelectImpl.java:2209)
at org.apache.openjpa.jdbc.sql.AbstractResult.next(AbstractResult.java:168)
at org.apache.openjpa.jdbc.kernel.SelectResultObjectProvider.next(SelectResultObjectProvider.java:99)
at org.apache.openjpa.lib.rop.EagerResultList.<init>(EagerResultList.java:35)
at org.apache.openjpa.kernel.QueryImpl.toResult(QueryImpl.java:1219)
at org.apache.openjpa.kernel.QueryImpl.execute(QueryImpl.java:987)
at org.apache.openjpa.kernel.QueryImpl.execute(QueryImpl.java:839)
at org.apache.openjpa.kernel.QueryImpl.execute(QueryImpl.java:770)
at kodo.kernel.KodoQuery.execute(KodoQuery.java:47)
at org.apache.openjpa.kernel.DelegatingQuery.execute(DelegatingQuery.java:525)
at org.apache.openjpa.persistence.QueryImpl.execute(QueryImpl.java:229)
at org.apache.openjpa.persistence.QueryImpl.getResultList(QueryImpl.java:269)
at kodo.persistence.KodoQueryImpl.getResultList(KodoQueryImpl.java:213)
at kodo.persistence.KodoQueryImpl.getResultList(KodoQueryImpl.java:213)
at com.company.buapp.buslogic.helpers.ApproveApplicationHelper.createNewTransactionsExcludingApplication(ApproveApplicationHelper.java:167)
at com.company.buapp.buslogic.helpers.ApproveApplicationHelper.createNewTransactions(ApproveApplicationHelper.java:129)
at com.company.buapp.buslogic.helpers.ApproveApplicationHelper.stageAction(ApproveApplicationHelper.java:74)
at com.company.buapp.buslogic.session.ApproveApplicationSessionBean.performAction(ApproveApplicationSessionBean.java:348)
at sun.reflect.GeneratedMethodAccessor2150.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at com.bea.core.repackaged.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:281)
at com.bea.core.repackaged.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:187)
at com.bea.core.repackaged.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:154)
at com.bea.core.repackaged.springframework.aop.support.DelegatingIntroductionInterceptor.doProceed(DelegatingIntroductionInterceptor.java:126)
at com.bea.core.repackaged.springframework.aop.support.DelegatingIntroductionInterceptor.invoke(DelegatingIntroductionInterceptor.java:114)
at com.bea.core.repackaged.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:176)
at weblogic.ejb.container.injection.EnvironmentInterceptor.invoke(EnvironmentInterceptor.java:68)
at com.bea.core.repackaged.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:176)
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:176)
at com.bea.core.repackaged.springframework.aop.support.DelegatingIntroductionInterceptor.doProceed(DelegatingIntroductionInterceptor.java:126)
at com.bea.core.repackaged.springframework.aop.support.DelegatingIntroductionInterceptor.invoke(DelegatingIntroductionInterceptor.java:114)
at com.bea.core.repackaged.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:176)
at com.bea.core.repackaged.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:210)
at $Proxy365.performAction(Unknown Source)
at com.company.buapp.buslogic.session.ApproveApplicationSessionBean_gc4fhc_ApproveApplicationSessionLocalImpl.performAction(ApproveApplicationSessionBean_gc4fhc_ApproveApplicationSessionLocalImpl.java:148)
at com.company.buapp.si.ApplicationWS.performAction(ApplicationWS.java:114)
at sun.reflect.GeneratedMethodAccessor2149.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at weblogic.wsee.jaxws.WLSInvoker.invoke(WLSInvoker.java:50)
at weblogic.wsee.jaxws.WLSInvoker.invoke(WLSInvoker.java:42)
at com.sun.xml.ws.server.sei.EndpointMethodHandler.invoke(EndpointMethodHandler.java:247)
at com.sun.xml.ws.server.sei.SEIInvokerPipe.process(SEIInvokerPipe.java:97)
at weblogic.wsee.jaxws.MonitoringPipe.process(MonitoringPipe.java:98)
at com.sun.xml.ws.protocol.soap.ServerMUPipe.process(ServerMUPipe.java:62)
at com.sun.xml.ws.server.WSEndpointImpl$1.process(WSEndpointImpl.java:139)
at com.sun.xml.ws.transport.http.HttpAdapter$HttpToolkit.handle(HttpAdapter.java:153)
at com.sun.xml.ws.transport.http.HttpAdapter.handle(HttpAdapter.java:235)
at com.sun.xml.ws.transport.http.servlet.ServletAdapter.handle(ServletAdapter.java:97)
at weblogic.wsee.jaxws.HttpServletAdapter.post(HttpServletAdapter.java:36)
at weblogic.wsee.jaxws.JAXWSServlet.doPost(JAXWSServlet.java:218)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:727)
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:3395)
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)

This was actually my first conclusion as well. But when I went to the Data Source for this connection, I found it's a non-transactional driver. That's what made me go back and give the trace a second look. I don't see any references to the Data Source in question. It's OpenJPA stuff and Session persistence stuff.Non-XA drivers can still participate in an XA transaction via a variety of JDBC data source options - for example, labeled "1PC" and "LLR" on the console. (If you want to understand the particulars search for "JTS" or "LLR" in the JDBC edocs).
You seem to be suggesting maybe the setting can be made in a config doc, possibly of the app itself, right? Right. EJBs have a transaction-timeout attribute.
As opposed to setting it in the console. WebLogic has a domain wide default transaction-timeout setting that can be set on the console, but I tend not to recommend using it. In addition, there's something called a "deployment plan" which can be used to override some of the common EJB attributes via configuration, but I'm not personally familiar with its usage.
But isn't the setting vapor if we're using a nonXA driver?No.
I wonder if this thing couldn't be telling me it's waiting on the persistence subsystem to come available to store simple session data? Sometimes the problem is that there are periodic app requests that are more complex/larger than others. Sometimes the system is simply overloaded, and takes 30 seconds to honor a request that might normally take 10 seconds.
That other app is all about persistence. What if app2 is sucking some persistence subsystem dry and app 1 is waiting just to store session data? Could be.
If the nonXA thing really does kill the quick timeout workaround, how could I health-check the persistence subsystem?Don't know. At a wild guess I'd check for CPU's at 100% on all involved serves, and examine database stats.

About "the transaction is no longer active" exception

Hi all
My application is deployed on the weblogic 7 SP2 and whenever i am trying to ship the orders which involves the Database interactions i am getting the following error. I increased the transaction time out periods to 5000 seconds in config.xml but still i am getting following exception.
can anybody tell me what is excat cause of the following exception and what things i need to do to resolve the exception
x.x.x.x: MSG: Failed to get Fulfillment Center Sourced Orders java.rmi.RemoteException: EJB Exception: ; nested exception is:
     x.x.x.x: MSG: java.sql.SQLException: The transaction is no longer active - status: 'Marked rollback. [Reason=weblogic.transaction.internal.AppSetRollbackOnlyException]'. No further JDBC access is allowed within this transaction.The transaction is no longer active - status: 'Marked rollback. [Reason=weblogic.transaction.internal.AppSetRollbackOnlyException]'. No further JDBC access is allowed within this transaction. TIME: 0EJB Exception: ; nested exception is:
     x.x.x.x: MSG: java.sql.SQLException: The transaction is no longer active - status: 'Marked rollback. [Reason=weblogic.transaction.internal.AppSetRollbackOnlyException]'. No further JDBC access is allowed within this transaction.The transaction is no longer active - status: 'Marked rollback. [Reason=weblogic.transaction.internal.AppSetRollbackOnlyException]'. No further JDBC access is allowed within this transaction. TIME: 0ERROR CODE: 30006 TIME: 1178858558476
     at x.x.x.x.x.ConfirmOrderBean.getAllNewOrdersForStore(ConfirmOrderBean.java:107)
     at jsp_servlet._fulfill.__confirm._jspService(__confirm.java:338)
     at weblogic.servlet.jsp.JspBase.service(JspBase.java:27)
     at weblogic.servlet.internal.ServletStubImpl$ServletInvocationAction.run(ServletStubImpl.java:1058)
     at weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:401)
     at weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:306)
     at weblogic.servlet.internal.WebAppServletContext$ServletInvocationAction.run(WebAppServletContext.java:5445)
     at weblogic.security.service.SecurityServiceManager.runAs(SecurityServiceManager.java:780)
     at weblogic.servlet.internal.WebAppServletContext.invokeServlet(WebAppServletContext.java:3105)
     at weblogic.servlet.internal.ServletRequestImpl.execute(ServletRequestImpl.java:2588)
     at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:213)
     at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:189)
Thanx in advance
Reagrds
Pandurang

Hi all
My application is deployed on the weblogic 7 SP2 and whenever i am trying to ship the orders which involves the Database interactions i am getting the following error. I increased the transaction time out periods to 5000 seconds in config.xml but still i am getting following exception.
can anybody tell me what is excat cause of the following exception and what things i need to do to resolve the exception
x.x.x.x: MSG: Failed to get Fulfillment Center Sourced Orders java.rmi.RemoteException: EJB Exception: ; nested exception is:
     x.x.x.x: MSG: java.sql.SQLException: The transaction is no longer active - status: 'Marked rollback. [Reason=weblogic.transaction.internal.AppSetRollbackOnlyException]'. No further JDBC access is allowed within this transaction.The transaction is no longer active - status: 'Marked rollback. [Reason=weblogic.transaction.internal.AppSetRollbackOnlyException]'. No further JDBC access is allowed within this transaction. TIME: 0EJB Exception: ; nested exception is:
     x.x.x.x: MSG: java.sql.SQLException: The transaction is no longer active - status: 'Marked rollback. [Reason=weblogic.transaction.internal.AppSetRollbackOnlyException]'. No further JDBC access is allowed within this transaction.The transaction is no longer active - status: 'Marked rollback. [Reason=weblogic.transaction.internal.AppSetRollbackOnlyException]'. No further JDBC access is allowed within this transaction. TIME: 0ERROR CODE: 30006 TIME: 1178858558476
     at x.x.x.x.x.ConfirmOrderBean.getAllNewOrdersForStore(ConfirmOrderBean.java:107)
     at jsp_servlet._fulfill.__confirm._jspService(__confirm.java:338)
     at weblogic.servlet.jsp.JspBase.service(JspBase.java:27)
     at weblogic.servlet.internal.ServletStubImpl$ServletInvocationAction.run(ServletStubImpl.java:1058)
     at weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:401)
     at weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:306)
     at weblogic.servlet.internal.WebAppServletContext$ServletInvocationAction.run(WebAppServletContext.java:5445)
     at weblogic.security.service.SecurityServiceManager.runAs(SecurityServiceManager.java:780)
     at weblogic.servlet.internal.WebAppServletContext.invokeServlet(WebAppServletContext.java:3105)
     at weblogic.servlet.internal.ServletRequestImpl.execute(ServletRequestImpl.java:2588)
     at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:213)
     at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:189)
Thanx in advance
Reagrds
Pandurang

Regarding "the transaction is no longer active" exception

Hi all
My application is deployed on the weblogic 7 SP2 and whenever i am trying to ship the orders which involves the Database interactions i am getting the following error. I increased the transaction time out periods to 5000 seconds in config.xml but still i am getting following exception.
can anybody tell me what is excat cause of the following exception and what things i need to do to resolve the exception
x.x.x.x: MSG: Failed to get Fulfillment Center Sourced Orders java.rmi.RemoteException: EJB Exception: ; nested exception is:
x.x.x.x: MSG: java.sql.SQLException: The transaction is no longer active - status: 'Marked rollback. [Reason=weblogic.transaction.internal.AppSetRollbackOnlyException]'. No further JDBC access is allowed within this transaction.The transaction is no longer active - status: 'Marked rollback. [Reason=weblogic.transaction.internal.AppSetRollbackOnlyException]'. No further JDBC access is allowed within this transaction. TIME: 0EJB Exception: ; nested exception is:
x.x.x.x: MSG: java.sql.SQLException: The transaction is no longer active - status: 'Marked rollback. [Reason=weblogic.transaction.internal.AppSetRollbackOnlyException]'. No further JDBC access is allowed within this transaction.The transaction is no longer active - status: 'Marked rollback. [Reason=weblogic.transaction.internal.AppSetRollbackOnlyException]'. No further JDBC access is allowed within this transaction. TIME: 0ERROR CODE: 30006 TIME: 1178858558476
at x.x.x.x.x.ConfirmOrderBean.getAllNewOrdersForStore(ConfirmOrderBean.java:107)
at jsp_servlet._fulfill.__confirm._jspService(__confirm.java:338)
at weblogic.servlet.jsp.JspBase.service(JspBase.java:27)
at weblogic.servlet.internal.ServletStubImpl$ServletInvocationAction.run(ServletStubImpl.java:1058)
at weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:401)
at weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:306)
at weblogic.servlet.internal.WebAppServletContext$ServletInvocationAction.run(WebAppServletContext.java:5445)
at weblogic.security.service.SecurityServiceManager.runAs(SecurityServiceManager.java:780)
at weblogic.servlet.internal.WebAppServletContext.invokeServlet(WebAppServletContext.java:3105)
at weblogic.servlet.internal.ServletRequestImpl.execute(ServletRequestImpl.java:2588)
at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:213)
at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:189)
Thanx in advance
Reagrds
Pandurang

pandurang pokharkar wrote:
Hi all
My application is deployed on the weblogic 7 SP2 and whenever i am trying to ship the orders which involves the Database interactions i am getting the following error. I increased the transaction time out periods to 5000 seconds in config.xml but still i am getting following exception.
can anybody tell me what is excat cause of the following exception and what things i need to do to resolve the exception
x.x.x.x: MSG: Failed to get Fulfillment Center Sourced Orders java.rmi.RemoteException: EJB Exception: ; nested exception is:
x.x.x.x: MSG: java.sql.SQLException: The transaction is no longer active - status: 'Marked rollback. [Reason=weblogic.transaction.internal.AppSetRollbackOnlyException]'. No further JDBC access is allowed within this transaction.The transaction is no longer active - status: 'Marked rollback. [Reason=weblogic.transaction.internal.AppSetRollbackOnlyException]'. No further JDBC access is allowed within this transaction. TIME: 0EJB Exception: ; nested exception is:
x.x.x.x: MSG: java.sql.SQLException: The transaction is no longer active - status: 'Marked rollback. [Reason=weblogic.transaction.internal.AppSetRollbackOnlyException]'. No further JDBC access is allowed within this transaction.The transaction is no longer active - status: 'Marked rollback. [Reason=weblogic.transaction.internal.AppSetRollbackOnlyException]'. No further JDBC access is allowed within this transaction. TIME: 0ERROR CODE: 30006 TIME: 1178858558476
at x.x.x.x.x.ConfirmOrderBean.getAllNewOrdersForStore(ConfirmOrderBean.java:107)
at jsp_servlet._fulfill.__confirm._jspService(__confirm.java:338)
at weblogic.servlet.jsp.JspBase.service(JspBase.java:27)
at weblogic.servlet.internal.ServletStubImpl$ServletInvocationAction.run(ServletStubImpl.java:1058)
at weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:401)
at weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:306)
at weblogic.servlet.internal.WebAppServletContext$ServletInvocationAction.run(WebAppServletContext.java:5445)
at weblogic.security.service.SecurityServiceManager.runAs(SecurityServiceManager.java:780)
at weblogic.servlet.internal.WebAppServletContext.invokeServlet(WebAppServletContext.java:3105)
at weblogic.servlet.internal.ServletRequestImpl.execute(ServletRequestImpl.java:2588)
at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:213)
at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:189)
Thanx in advance
Reagrds
PandurangIt is pretty much as it says. While your code is processing this transaction,
in the backround in another thread, the transaction controller has discovered
that this transaction has been running longer than it's configured maximum
time, so the coordinator rolls it back and tells every JDBC object involved
to throw the exception you see the next time any of them are asked to run
another method. Turn on the JTA logging, or instrument your code to show step
by step the progress of your transactions, so you can see what call(s) take
too much time.
Joe

af:query marks the DataControl as modified

Hi guys,
I am developing an ADF Rich Faces application with JDeveloper 11g. I am using <af:query> search forms. When I enter a value in some criteria field in a search form, then the corresponding DataControl gets marked as modified (DataControl.isTransactionModified() starts returning <true>). I suspect that this is because each setAttribute() method invocation through a value data binding marks the DataControl as modified. Quick query forms (<af:quickQuery>) do not mark the DataControl as modified.
I do not want the DataControl to be marked as modified because my application checks for pending changes this way (using DataControl.isTransactionModified() method). Note that the current status (enabled/disabled) of standard Commit and Rollback action bindings is wired to this method too.
Note, also, that the method ApplicationModule.getTransaction().isDirty() is not appropriate for checking for pending changes because when I create and insert a new empty row in some ViewObject then the Transaction object becomes "dirty" automatically without any real data modifications.
Does anybody know if I could either avoid or workaround this effect of <af:query> forms?
Thanks in advance.

We have this problem to. it must be a bug.
Also we had other problems when we have <af:query> in transaction forms like validations fire when 'Advanced search' button is pressed
So we splited query forms from transaction forms or put <af:query> in popup
we still use ApplicationModule.getTransaction().isDirty() since we want to know changes also for new rows (since you cant distinguish if data are added to new row or not)

NAMED_SEQUENCEs: The transaction is no longer active

Hi all,
          I am currently trying to get Petstore 1.3.1 going on WLS 7.0.0.1 an got
          into quite some trouble (btw, does anyone have experience with this
          cofiguration?). After successful deployment in /application I tried the
          "populate database" link on ~/petstore/index.jsp and got:
          java.sql.SQLException: The transaction is no longer active (status = Committed). No further JDBC access is allowed within this transaction.
               at weblogic.jdbc.jts.Connection.checkIfRolledBack(Connection.java:541)
               at weblogic.jdbc.jts.ResultSet.close(ResultSet.java:293)
               at weblogic.jdbc.rmi.internal.ResultSetImpl.close(ResultSetImpl.java:144)
               at weblogic.jdbc.rmi.SerialResultSet.close(SerialResultSet.java:96)
               at weblogic.jdbc.rmi.SerialResultSet.close(SerialResultSet.java:87)
               at weblogic.ejb20.cmp.rdbms.RDBMSPersistenceManager.releaseResultSet(RDBMSPersistenceManager.java:1797)
               at weblogic.ejb20.cmp.rdbms.RDBMSPersistenceManager.releaseResources(RDBMSPersistenceManager.java:1679)
               at weblogic.ejb20.cmp.rdbms.RDBMSPersistenceManager.execGenKeyNamedSequenceTableUpdateAndQuery(RDBMSPersistenceManager.java:1489)
               at weblogic.ejb20.cmp.rdbms.RDBMSPersistenceManager.getNextGenKeyNamedSequenceTable(RDBMSPersistenceManager.java:1307)
               at com.sun.j2ee.blueprints.address.ejb.AddressEJB_fvu9sn__WebLogic_CMP_RDBMS.ejbCreate(AddressEJB_fvu9sn__WebLogic_CMP_RDBMS.java:1723)
               at java.lang.reflect.Method.invoke(Native Method)
               at weblogic.ejb20.manager.DBManager.create(DBManager.java:737)
               at weblogic.ejb20.manager.DBManager.localCreate(DBManager.java:716)
               at weblogic.ejb20.internal.EntityEJBLocalHome.create(EntityEJBLocalHome.java:182)
               at com.sun.j2ee.blueprints.address.ejb.AddressEJB_fvu9sn_LocalHomeImpl.create(AddressEJB_fvu9sn_LocalHomeImpl.java:155)
               at com.sun.j2ee.blueprints.petstore.tools.populate.AddressPopulator.createAddress(AddressPopulator.java:94)     at com.sun.j2ee.blueprints.petstore.tools.populate.AddressPopulator.access$7(AddressPopulator.java)
               at com.sun.j2ee.blueprints.petstore.tools.populate.AddressPopulator$1.create(AddressPopulator.java:73)
               at com.sun.j2ee.blueprints.petstore.tools.populate.XMLDBHandler.endElement(XMLDBHandler.java:145)
               at org.xml.sax.helpers.XMLFilterImpl.endElement(XMLFilterImpl.java:595)
               at com.sun.j2ee.blueprints.petstore.tools.populate.XMLDBHandler.endElement(XMLDBHandler.java:158)
               at weblogic.apache.xerces.parsers.SAXParser.endElement(SAXParser.java:1411)
               at weblogic.apache.xerces.validators.common.XMLValidator.callEndElement(XMLValidator.java:1613)
               at weblogic.apache.xerces.framework.XMLDocumentScanner$ContentDispatcher.dispatch(XMLDocumentScanner.java:1219)
               at weblogic.apache.xerces.framework.XMLDocumentScanner.parseSome(XMLDocumentScanner.java:396)
               at weblogic.apache.xerces.framework.XMLParser.parse(XMLParser.java:1119)
               at weblogic.xml.jaxp.WebLogicXMLReader.parse(WebLogicXMLReader.java:135)
               at weblogic.xml.jaxp.RegistryXMLReader.parse(RegistryXMLReader.java:133)
               at org.xml.sax.helpers.XMLFilterImpl.parse(XMLFilterImpl.java:371)
               at org.xml.sax.helpers.XMLFilterImpl.parse(XMLFilterImpl.java:371)
               at org.xml.sax.helpers.XMLFilterImpl.parse(XMLFilterImpl.java:371)
               at org.xml.sax.helpers.XMLFilterImpl.parse(XMLFilterImpl.java:371)
               at org.xml.sax.helpers.XMLFilterImpl.parse(XMLFilterImpl.java:371)
               at org.xml.sax.helpers.XMLFilterImpl.parse(XMLFilterImpl.java:371)
               at org.xml.sax.helpers.XMLFilterImpl.parse(XMLFilterImpl.java:371)
               at org.xml.sax.helpers.XMLFilterImpl.parse(XMLFilterImpl.java:371)
               at org.xml.sax.helpers.XMLFilterImpl.parse(XMLFilterImpl.java:371)
               at org.xml.sax.helpers.XMLFilterImpl.parse(XMLFilterImpl.java:371)
               at org.xml.sax.helpers.XMLFilterImpl.parse(XMLFilterImpl.java:371)
               at org.xml.sax.helpers.XMLFilterImpl.parse(XMLFilterImpl.java:371)
               at org.xml.sax.helpers.XMLFilterImpl.parse(XMLFilterImpl.java:371)
               at com.sun.j2ee.blueprints.petstore.tools.populate.PopulateServlet.populate(PopulateServlet.java:162)
               at com.sun.j2ee.blueprints.petstore.tools.populate.PopulateServlet.doPost(PopulateServlet.java:118)
               at com.sun.j2ee.blueprints.petstore.tools.populate.PopulateServlet.doGet(PopulateServlet.java:106)
               at javax.servlet.http.HttpServlet.service(HttpServlet.java:740)
               at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
               at weblogic.servlet.internal.ServletStubImpl$ServletInvocationAction.run(ServletStubImpl.java:945)
               at weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:332)
               at weblogic.servlet.internal.TailFilter.doFilter(TailFilter.java:20)
               at weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:27)
               at com.sun.j2ee.blueprints.signon.web.SignOnFilter.doFilter(SignOnFilter.java:151)
               at weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:27)
               at com.sun.j2ee.blueprints.encodingfilter.web.EncodingFilter.doFilter(EncodingFilter.java:77)
               at weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:27)
               at weblogic.servlet.internal.WebAppServletContext$ServletInvocationAction.run(WebAppServletContext.java:5366)
               at weblogic.security.service.SecurityServiceManager.runAs(SecurityServiceManager.java:721)
               at weblogic.servlet.internal.WebAppServletContext.invokeServlet(WebAppServletContext.java:3043)
               at weblogic.servlet.internal.ServletRequestImpl.execute(ServletRequestImpl.java:2468)
               at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:152)
               at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:133)
          and similar traces for ContactInfo, CreditCard, Account, Profile, ...
          I nevertheless get to the main screen of the Petstore as if everything
          worked well. In fact, it seems like the DB got populated somewhat
          correctly; only tbe named sequence tables are unchanged (btw: are the
          named sequence tables expected to be auto-created with
          create-default-dbms-tables enabled?). The strange thing is that every
          correct row (in my case having the even IDs) is followd by an all (except the
          odd numbered ID field) "NULL" row. This does not happen in all
          ...EJBTABLEs --- Address and ContactInfo for example are affected, but Profile
          is not.
          It seems as if ordering a rattlesnake would work well, even though more
          of the same type of Execptions appear in the jdbc log. I suspect that the
          trouble will start when the 10 cached ID are exhausted.
          I just tried the Petstore 1.3 example provided with WLS 7.0.0.1 on a Linux
          machine and WLS 7.0 on an NT machine andfound petty much the same
          exception after enabling the jdbc log:
          java.sql.SQLException: The transaction is no longer active (status = Committed). No further JDBC access is allowed within this transaction.
               at weblogic.jdbc.jts.Connection.checkIfRolledBack(Connection.java:541)
               at weblogic.jdbc.jts.ResultSet.close(ResultSet.java:293)
               at weblogic.jdbc.rmi.internal.ResultSetImpl.close(ResultSetImpl.java:144)
               at weblogic.jdbc.rmi.SerialResultSet.close(SerialResultSet.java:96)
               at weblogic.jdbc.rmi.SerialResultSet.close(SerialResultSet.java:87)
               at weblogic.ejb20.cmp.rdbms.RDBMSPersistenceManager.releaseResultSet(RDBMSPersistenceManager.java:1797)
               at weblogic.ejb20.cmp.rdbms.RDBMSPersistenceManager.releaseResources(RDBMSPersistenceManager.java:1679)
               at weblogic.ejb20.cmp.rdbms.RDBMSPersistenceManager.execGenKeyNamedSequenceTableUpdateAndQuery(RDBMSPersistenceManager.java:1489)
               at weblogic.ejb20.cmp.rdbms.RDBMSPersistenceManager.getNextGenKeyNamedSequenceTable(RDBMSPersistenceManager.java:1307)
               at com.sun.j2ee.blueprints.po.address.ejb.AddressEJB_fvu9sn__WebLogic_CMP_RDBMS.ejbCreate(AddressEJB_fvu9sn__WebLogic_CMP_RDBMS.java:1755)
               at java.lang.reflect.Method.invoke(Native Method)
               at weblogic.ejb20.manager.DBManager.create(DBManager.java:737)
               at weblogic.ejb20.manager.DBManager.localCreate(DBManager.java:716)
               at weblogic.ejb20.internal.EntityEJBLocalHome.create(EntityEJBLocalHome.java:182)
               at com.sun.j2ee.blueprints.po.address.ejb.AddressEJB_fvu9sn_LocalHomeImpl.create(AddressEJB_fvu9sn_LocalHomeImpl.java:86)
               at com.sun.j2ee.blueprints.po.purchaseorder.ejb.PurchaseOrderHelper.persistPoCMRInfo(PurchaseOrderHelper.java:116)
               at com.sun.j2ee.blueprints.po.purchaseorder.ejb.PurchaseOrderHelper.persistPO(PurchaseOrderHelper.java:164)     at com.sun.j2ee.blueprints.opc.ejb.MsgBean.doWork(MsgBean.java:103)
               at com.sun.j2ee.blueprints.opc.ejb.MsgBean.onMessage(MsgBean.java:72)
               at weblogic.ejb20.internal.MDListener.execute(MDListener.java:348)
               at weblogic.ejb20.internal.MDListener.transactionalOnMessage(MDListener.java:282)
               at weblogic.ejb20.internal.MDListener.onMessage(MDListener.java:263)
               at weblogic.jms.client.JMSSession.onMessage(JMSSession.java:2309)
               at weblogic.jms.client.JMSSession.execute(JMSSession.java:2232)
               at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:152)
               at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:133)
          Is there a problem with my general setup maybe, or is this exception to
          be ignored? Is that a known issue with Petstore 1.3/WLS7?
          Kai


Tyson Norris wrote:
Hello -
We are attempting to use a design where a connection will remain in use over multiple
transactions.
Is there any way to get weblogic to allow this?No, at least not jts connections. Non-XA connections need our management to
ensure all the work gets committed or rolled back atomically. It doesn't
cost anything to always obtain jts connections in the context of the tx
they are needed.
Besides XA, you could get a plain non-transactional connection and do your
own jdbc commits/rollbacks...
Joe
>
We are currently experiencing the stack trace below, when a database read is
attempting to use the same connection as the previously committed tx.
Thanks for any advice.
Tyson
org.springframework.jdbc.UncategorizedSQLException: (HibernateAccessor): encountered
SQLException [The transaction is no longer active - status: 'Committed'. No further
JDBC access is allowed within this transaction.]; nested exception is java.sql.SQLException:
The transaction is no longer active - status: 'Committed'. No further JDBC access
is allowed within this transaction. java.sql.SQLException: The transaction is
no longer active - status: 'Committed'. No further JDBC access is allowed within
this transaction. at weblogic.jdbc.wrapper.JTSConnection.checkIfRolledBack(JTSConnection.java:118)
at weblogic.jdbc.wrapper.JTSConnection.checkConnection(JTSConnection.java:127)
at weblogic.jdbc.wrapper.Connection.prepareStatement(Connection.java:324) at weblogic.jdbc.wrapper.JTSConnection.prepareStatement(JTSConnection.java:426)
at com.benefitpoint.cmp.hibernate.AbstractDataManager$2.doInHibernate(AbstractDataManager.java:501)
at org.springframework.orm.hibernate.HibernateTemplate.execute(HibernateTemplate.java:150)
at com.benefitpoint.cmp.hibernate.AbstractDataManager.execRawSqlPreparedStatement(AbstractDataManager.java:568)
at

The transaction is no longer active - status: 'Committed'.

Hello -
We are attempting to use a design where a connection will remain in use over multiple
transactions.
Is there any way to get weblogic to allow this?
We are currently experiencing the stack trace below, when a database read is
attempting to use the same connection as the previously committed tx.
Thanks for any advice.
Tyson
org.springframework.jdbc.UncategorizedSQLException: (HibernateAccessor): encountered
SQLException [The transaction is no longer active - status: 'Committed'. No further
JDBC access is allowed within this transaction.]; nested exception is java.sql.SQLException:
The transaction is no longer active - status: 'Committed'. No further JDBC access
is allowed within this transaction. java.sql.SQLException: The transaction is
no longer active - status: 'Committed'. No further JDBC access is allowed within
this transaction. at weblogic.jdbc.wrapper.JTSConnection.checkIfRolledBack(JTSConnection.java:118)
at weblogic.jdbc.wrapper.JTSConnection.checkConnection(JTSConnection.java:127)
at weblogic.jdbc.wrapper.Connection.prepareStatement(Connection.java:324) at weblogic.jdbc.wrapper.JTSConnection.prepareStatement(JTSConnection.java:426)
at com.benefitpoint.cmp.hibernate.AbstractDataManager$2.doInHibernate(AbstractDataManager.java:501)
at org.springframework.orm.hibernate.HibernateTemplate.execute(HibernateTemplate.java:150)
at com.benefitpoint.cmp.hibernate.AbstractDataManager.execRawSqlPreparedStatement(AbstractDataManager.java:568)
at

Tyson Norris wrote:
Hello -
We are attempting to use a design where a connection will remain in use over multiple
transactions.
Is there any way to get weblogic to allow this?No, at least not jts connections. Non-XA connections need our management to
ensure all the work gets committed or rolled back atomically. It doesn't
cost anything to always obtain jts connections in the context of the tx
they are needed.
Besides XA, you could get a plain non-transactional connection and do your
own jdbc commits/rollbacks...
Joe
>
We are currently experiencing the stack trace below, when a database read is
attempting to use the same connection as the previously committed tx.
Thanks for any advice.
Tyson
org.springframework.jdbc.UncategorizedSQLException: (HibernateAccessor): encountered
SQLException [The transaction is no longer active - status: 'Committed'. No further
JDBC access is allowed within this transaction.]; nested exception is java.sql.SQLException:
The transaction is no longer active - status: 'Committed'. No further JDBC access
is allowed within this transaction. java.sql.SQLException: The transaction is
no longer active - status: 'Committed'. No further JDBC access is allowed within
this transaction. at weblogic.jdbc.wrapper.JTSConnection.checkIfRolledBack(JTSConnection.java:118)
at weblogic.jdbc.wrapper.JTSConnection.checkConnection(JTSConnection.java:127)
at weblogic.jdbc.wrapper.Connection.prepareStatement(Connection.java:324) at weblogic.jdbc.wrapper.JTSConnection.prepareStatement(JTSConnection.java:426)
at com.benefitpoint.cmp.hibernate.AbstractDataManager$2.doInHibernate(AbstractDataManager.java:501)
at org.springframework.orm.hibernate.HibernateTemplate.execute(HibernateTemplate.java:150)
at com.benefitpoint.cmp.hibernate.AbstractDataManager.execRawSqlPreparedStatement(AbstractDataManager.java:568)
at

Short dump with the transaction CJ02

Hello, this is my first thread in the forum. I hope to solve my problem.
It is necesary to say you that my english is very poor, is not so good. Sorry for that.
When i use the transaction CJ02 to finish or close a project, appears an error when i save it. The steps are the followings:
1- Run the transaction CJ02 with a WBS element
2- Mark the line of the WBS element
3- Select then button Settlement rule
4- Fill 4 items in the next screen to distribution rules (the % is 100)
5- Back with green arrow
6- Fill the field Cost Center Req
7- Save
After a few seconds appears the dump:
<b>ABAP runtime errors    MESSAGE_TYPE_X
       Occurred on     20.11.2006 at 11:07:09
>> Short dump has not been completely stored. It is too big.
The current application triggered a termination with a short dump.
Error analysis
Short text of error message:
Nested call of PERFORM ON COMMIT:
Long text of error message:
Diagnosis
     During processing of a routine called using PERFORM ... ON COMMIT,
     the system attempted to call PERFORM ... ON COMMIT again. Nesting
     of this is not allowed.
System Response
Procedure
     The program indicated after "Caller:" must be changed. This is the
     program that calls the routine indicated after "Form:" during
     COMMIT processing. This routine is part of the program indicated
     after
     "Program:".
Procedure for System Administration
Technical information about the message:
Message classe...... 00
Number.............. 081
Variable 1.......... " "
Variable 2.......... " "
Variable 3.......... " "
Variable 4.......... " "
How to correct the error
If the error is in one of your own ABAP programs or an SAP program that
you have modified, try to correct it.
If the error occurred in a non-modified SAP program, you may be
able to find a solution in the SAP note system.
If you have access to the note system yourself, use the following
search criteria:
"MESSAGE_TYPE_X"
"SAPMSSY0 " or "SAPMSSY0 "
"%_ORDER_FORM_FOR_ROLLBACK"</b>
There are several notes that apparently solve the problem with support packages that are applied in our system (for example 397011 or 614553). Inthis case our system is updated.
Can you help me please.
Thanks
Gabriel.-

Hi
Are you really sure https://websmp101.sap-ag.de/~form/handler?_APP=01100107900000000342&_EVENT=REDIR&_NNUM=397011&_NLANG=E
is applied correctly ?
Try downloading with snote and see if it gets marked 'not relevant',
( are you on release 4.6 ? )
Given the nature of the problem ( and the fact that this issue is known ) , the best seems log an OSS support request
rgds
Dirk

Bean Managed Transactions and rollback

Hi Everybody,
I am using Bean Managed Transactions in a Message Bean which is called every some time by an EJB3 timer. This Message Bean subsequently calls a Session Bean which uses Container Managed Transactions and uses the default transaction attribute which is SUPPORTS. The Session Bean methods might sometime throw a System Exception(inheriting from RuntimeException) which will rollback the Bean Managed Transaction which was started from the Message Bean.
When this happens and I try to invoke userTransaction.rollback() I get invalid transaction state exception and I suppose this means that is already rolled back.
Is there a way to get another transaction or set the transaction back to a valid state so I can carry on with some persistence tasks or the only way to do that is by suppressing the RuntimeException and throwing an Application Exception having the *@ApplicationException(rollback=false)* annotation? Can I suppress a System Exception though?
Thank you in advance!

Saroj wrote:
Hi All,
I would like to know whether we can use JDBC Connection Object's commit and rollback
methods to control Transaction in Bean Managed Transactions or not.You may use the JDBC connection's transaction support from an EJB. That being said, you
need to understand that it won't be the transaction that started declaratively by the
EJB container nor would it be a bean-managed transaction started through
UserTransaction.
FWIW, I question why you'd want to do this though. I'd use container-managed
transactions and let the container handle this for you. The transaction manager
includes a 1PC optimization so it's not going to do an XA/2PC tx if you only have a
single resource in the tx. Also, the EJB container includes all the logic to properly
handle rollbacks when exceptions are thrown etc.
Finally, your code will more maintainable and reusable if you use the container-managed
tx + JTA resources. If I later wanted to call another EJB or another JTA resource (eg
JMS perhaps) I could do it without having to rewrite all of your code.
-- Rob
>
>
Why is it required that we should use Java Transaction API to control the Transaction
in Our Beans?
I understand that if we are using Multiple Resources and need to use Transaction
then going for JTA makes sense. If I am using only Resource,for example, Only One
Connection then we should be able to use Connection's Transaction control.
I understand that other way to do the transaction is to use Container's transaction
services.
Please respond at the earliest.
Thanks in Advance,
Saroj

Marking the transaction as rollback in JPD

Similar Messages

Maybe you are looking for