JBoss Transaction Not Active - EJB 2.1 in JBOSS EAP 5.1.2

[limacon]

Hi,

I am hoping someone can help me on this transaction management problem.  Our application is working fine when it is running in Jboss EAP 4.3. But I am tasked to migrate this to JBoss 5.1.  I both tried JBoss EAP 5.1.1 and JBoss EAP 5.1.2 and I am having the same problem always.

2012-08-16 17:02:57,268 ERROR [STDERR] (Thread-33) org.jboss.util.NestedSQLException: Transaction is not active: tx=TransactionImple < ac, BasicAction: a410865:d86e:502cb72d:fc status: ActionStatus.COMMITTED >; - nested throwable: (javax.resource.ResourceException: Transaction is not active: tx=TransactionImple < ac, BasicAction: a410865:d86e:502cb72d:fc status: ActionStatus.COMMITTED >)

2012-08-16 17:02:57,268 ERROR [STDERR] (Thread-33) at org.jboss.resource.adapter.jdbc.WrapperDataSource.getConnection(WrapperDataSource.java:95)

2012-08-16 17:02:57,269 ERROR [STDERR] (Thread-33) at com.xxx.cx.base.JDBCPersistenceManagerBase.getConnection(JDBCPersistenceManagerBase.java:218)

2012-08-16 17:02:57,269 ERROR [STDERR] (Thread-33) at com.xxx.cx.job.JobJDBCMgr.updateWithActiveJob(JobJDBCMgr.java:318)

2012-08-16 17:02:57,269 ERROR [STDERR] (Thread-33) at com.xxx.cx.job.Job_Bean.ejbPassivate(Job_Bean.java:86)

2012-08-16 17:02:57,269 ERROR [STDERR] (Thread-33) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)

2012-08-16 17:02:57,269 ERROR [STDERR] (Thread-33) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)

2012-08-16 17:02:57,269 ERROR [STDERR] (Thread-33) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)

2012-08-16 17:02:57,270 ERROR [STDERR] (Thread-33) at java.lang.reflect.Method.invoke(Method.java:597)

2012-08-16 17:02:57,270 ERROR [STDERR] (Thread-33) at org.jboss.ejb.plugins.BMPPersistenceManager.passivateEntity(BMPPersistenceManager.java:538)

2012-08-16 17:02:57,270 ERROR [STDERR] (Thread-33) at

2012-08-16 17:02:57,275 ERROR [STDERR] (Thread-33)           ... 33 more

I placed in console outputs and it is having error on the following code:

DataSource datasource = null;

                    if (m_connection == null)

                    {

                              try

                              {

                                        System.out.println(">>>> Get DataSource here ...");

                                        datasource = getDataSource();

                                        System.out.println(">>>> Get Connection here ...");

                                        m_connection = datasource.getConnection();

                                        System.out.println(">>>> No Exception here ...");

                              }

                              catch(SQLException sqlExc)

                              {

                                        m_connection = null;

                                        System.out.println(">>>> Get connection failed ...");

                                        trace.message("Get connection failed");

                                        sqlExc.printStackTrace();

                                        throw new EJBException(sqlExc);

                              }

                              catch(EJBException ejbExc)

                              {

                                        m_connection = null;

                                        // getDataSource() failed: EJBException has already been constructed, so rethrow

                                        throw ejbExc;

                              }

                    }

                    return          m_connection;

I've already read lots post regarding this transaction not active issue: changing timeout, NullPointerException, etc.. but answers did not work for me.

Any idea or resolutions will be much grateful.

[mmusgrov]

It sounds like the connection is timing out. Could you post the stacktrace when you run it on EAP 5.x.

What happens if you extend the transaction timeout period (it defaults to 300 seconds). You can change the default via jbossts-properties.xml

Looking at the code for WrappedConnection.getConnection the failure is because it can't get a connection so can you also try increasing the size of your connection pool.

[limacon]

Hi Michael,

Thanks for the reply. I had attached the log in the original mesage. As for timeout like i said i did increase it to 600 then 6000 nothing happens. As for connection pool yes i did increase it from 2 to 10 to 20 still nothing happens.

Hoping for your kind reply.

[mmusgrov]

If there is an active transaction when you make a call to getConnection the container will try to enlist the connection in the transaction. But I notice from the stack trace that you are trying to get the connection from an afterCompletion synchronisation - ie the transaction has already finished (and that is why WrapperDataSource throws the exception). Is this what you are intending?

The behaviour change between EAP 4.3 and 5.x may be to do with the interpretation of whether the transaction context is defined during an afterCompletion callback. The spec does not define what the context should be so I expect that in EAP 4.3 we removed the context from the thread during afterCompletion and in 5.x we are leaving the context on the thread. The portable way to obtain a connection in an afterCompletion callback would be to suspend the transaction, get your datasource connection, complete your work and then resume the transaction.

[limacon]

Thanks again for your reply. This means a code change on our app side. I will study the flow of our app and will use your recommendation and get back to you.

[limacon]

Hi Mike,

Getting back to you again. We identified the issue of the problem but we are stucked on what direction to go. The original developers of the code put in some logic (db handling) on the ejbPassivate callback method. In this method (which you see above) has a indirect call to getConnection which causes the error.

public void ejbPassivate()

          {

     ......// SOME CODE HERE                  {

JobJDBCMgr m_mgr = (JobJDBCMgr) getJDBCManager();

                                        byte[] rawActiveJob = null;

                                        try

                                        {

                                                  rawActiveJob = m_activeJob.toByteArray();

                                        }

                                        catch( IOException e )

                                        {

                                                  throw new EJBException( e );

                                        }

                                        m_mgr.updateWithActiveJob(getJobData(), rawActiveJob, getId() );

                                             ......// SOME CODE HERE

                              }

                              else

     ......// SOME CODE HERE

                    }

     ......// SOME CODE HERE

          }

Most of the ejbCallBack methods have their own method variable JobJDBCMgr.  I tried to create CLASS level JDBC manager and it did solve the problem.. (TEMPORARILY).  This solution is working for some logic flow but NOT for all business logic (processes that takes around few seconds (10 secs or more)). Why I created a Class level variable - I want to retain the instance of the JobJDBCMgr Object when the Bean is pushed into the POOL.

Do you have any idea on how to resolve this issue? My timeout is set to a very high value (42000).

Hoping for your reply.

[limacon]

Hi Mike,

Its me again. Another solution that I thought of, is to remove the logic in the ejbPassivate. But doing so, will totally remov the business logic the previous developers set. We tried placing the logic in ejbStore (since based on the ejb call back sequence, ejbStore comes first before ejbPassivate) but its not working.

Hope you can shed light into this problem of ours.

[mmusgrov]

Try adding @TransactionAttribute(TransactionAttributeType.NOT_SUPPORTED) to you ejbPassivate method

[mmusgrov]

Or, depending on what business logic you have you may prefer REQUIRES_NEW (basically you need an attribute that will suspend the current transaction).

[limacon]

Thanks again. I tried requires new tx but it did not work. Let me try not supported and get back to you. Hoping this issue will not require us to migrate to ejb 3 as it will be a total overhaul.

[mmusgrov]

Thanks again. I tried requires new tx but it did not work. Let me try not supported and get back to you. Hoping this issue will not require us to migrate to ejb 3 as it will be a total overhaul.

This means that the annotation on the ejbPassivate method is being ignored. Can you find out whether there is still a transaction on the thread when ejbPassivate runs (lookup UserTransaction and call getStatus() on it).

Did you get any change in behavior, for example is the stacktrace different?

[limacon]

Hi Michael,

I have not looked up if transaction still exists but what i know its not active anymore due to an ejb auto commit through ejbStore. I believe this is a flaw on our system on why do we have a DB logic inside a passivate call (I think this is not a normal case).

Since I know that at ejbPassivate I dont have anymore transaction active, what i did was to create a new bean that has its own transaction. I created a stateless session bean that has its own db call and call this bean inside the passivate.

Thanks for your help again. If i find out more, will let you know.