Atomikos Forum

TransactionEssentials connection leak.

Hi everyone!

I am using Atomikos TransactionEssentials version 3.2.0 in a web application using Tomcat 5.5 and Oracle 9.2. I can´t undeply the application because there is a connection leaks that causes a OutOfMemoryError.

I have a servlet (only startup servlet) that initialize the TransacionManager (as shown in the atomikos documentation: http://www.atomikos.com/Documentation/Tomcat55SelfContainedWar) when the servlet initializes. When it´s destroyed, I close it.

When I deploy the WAR, I have some DAO´s that accesses a DB, and make queries to the DB like this:

<code>

public void init(){

try{
  Connection con=getConnection();
    con.executeQuery....
   
    recursiveQuery();

}finally{
  if (con!=null){
    con.close();
  }
}

public void recursiveQuery(){

  try{
    Connection con=getConnection();
      con.executeQuery....

    recursiveQuery();

  }finally{
    if (con!=null){
    con.close();
    }
  }

}

</code>

When this is executed, I checked that were 6 connections active in Oracle (didn´t the TransactionsEssentials pool have 5 connections by default?). When I undeploy the WAR, only ONE connection is closed, and the others are still alive, that´s why I get the OutOfMemoryError if I deploy/undeploy several times without restart the whole Tomcat server.

Some months ago I read something about a bug in the shutdown hook in TransactionsEssentials in Tomcat (which will be in the 3.3 release coming soon). This have any relation with my problem?

Thanks very much!!
Juan G Send private email
Tuesday, April 22, 2008
 
 
Hi,

I'm not sure your OutOfMemoryError is caused by a connection leak. Usually when an application has a connection leak the database gives up way before the application runs out of memory. A JDBC connection does not account more than a few hundred bytes (maybe a few kilobytes in extreme cases) in the JVM.

That's especially true with the current connection pool that has no upper limit: when the connection pool is empty and a new connection is requested, a new connection is created on the fly.

Are you using the SimpleDataSourceBean or the NonXaDataSourceBean ? There can be a huge difference between the two as the latter can somewhat recycle connections.

Also, do you close the SimpleDataSourceBean/NonXaDataSourceBean when the servlet context is destroyed ? Where did you put your JDBC driver's JAR file ? Also in the WEB-INF/lib ?

Your problem description is a bit vague so there are many different things that need to be checked. I would suggest profiling Tomcat to get the real cause of the memory leak because I've definitely never seen a connection leak ending up with an OutOfMemoryError.

Ludovic
Ludovic Orban Send private email
Wednesday, April 23, 2008
 
 
Thanks for your answer!

I will write below the context.xml where I configured the JTA data source:

<code>

<Resource name="jdbc/myOracle"           auth="Container"          type="com.atomikos.jdbc.SimpleDataSourceBean"              factory="org.apache.naming.factory.BeanFactory"              uniqueResourceName="jdbc/myOracle"                xaDataSourceClassName="oracle.jdbc.xa.client.OracleXADataSource"              exclusiveConnectionMode="false"              connectionPoolSize="5"              connectionTimeout="40"            xaDataSourceProperties="URL=...."/>

<Transaction factory="com.atomikos.icatch.jta.UserTransactionFactory"/>

</code>

So the answer toy your first question is "SimpleDataSouceBean"

Here is the code of the servlet when it inits and when it is destroyed:

<code>

public class LoadServlet extends HttpServlet {

    private UserTransactionManager utm;

    
    public void init(ServletConfig config) {
        try {
            // INIT OF  ATOMIKOS            
                  utm = new UserTransactionManager();
         utm.init();


        }catch(Exception e){
          ...
        }

      public void destroy() {

        if (utm != null) {
            utm.close();        
        }
    }


 }
</code>

And of course I put in web.xml the "load-on-startup" for this servlet to start. This servlet IS NEVER INVOKED, whe use it only to initialize different data.


The "jar" of Oracle are in the common/lib of Tomcat. The rest of "jar" are in WEB-INF/lib.

I didn´t mentioned I have the problem of the "lck" log files when I undeploy, and  then deploy. I have to delete them many times.

Thanks very much!
Juan G Send private email
Wednesday, April 23, 2008
 
 
Another important thing here, I tried with a ServletContextListener instead a servlet to init/close the UserTransactionManager, and the problem was still there.

Thanks!
Juan G Send private email
Wednesday, April 23, 2008
 
 
Could it be the "exclusiveConnectionMode"=true param in the context.xml  config which causes this connection leak and doesn´t closes them because of reusing the connections?
Juan G Send private email
Wednesday, April 23, 2008
 
 
I checked that this could be a problem with the pool. I realised I am using a custom connection pool. It seems that the two connection pools are connecting independently from each other, and making extra connections...

If I configure the

  connectionPoolSize="1"

in context.xml and I configure the other pool with size=0, I see there are two connections active, so there is a problem...

I read the article about the external connection pools here http://wiki.atomikos.org/Documentation/ExternalConnectionPool, but I didn´t find any solution about it...

How could I disable one of the two pools?

Thanks very much..
Juan G Send private email
Thursday, April 24, 2008
 
 
I have this problem too:

http://www.atomikos-support.com/forums/viewtopic.php?t=1296

Perhaps it´s something about the Atomikos Pool or Oracle XA Datasource...
Juan G Send private email
Thursday, April 24, 2008
 
 
Hi,

From your original post it wasn't clear that you were restarting the webapp when seeing the leak.

It could be related to http://www.atomikos-support.com/forums/viewtopic.php?t=1296 - I am not sure with the limited information you give.

However, I would suggest the following:

-try to upgrade to 3.2.3 (available online via our site)
-if the problem persists, post a tm.out here, produced in DEBUG mode
-if all else fails, wait for 3.3 to come out - this will definitely fix http://www.atomikos-support.com/forums/viewtopic.php?t=1296

If you need faster or more in-depth help then I suggest that you contact sales@atomikos.com for developer support.

HTH
Guy
Guy Pardon Send private email
Thursday, April 24, 2008
 
 
Hi Guy!

Thanks for your answer...

I upgraded to the latest version (3.2.3) and still the same problem. It seems there is one connection more than the connectionPoolSize attribute in the context.xml, don´t know why. When it undeploys, it only closes one connection (no matter how many connections are), the rest are still alive (I checked it in Oracle Enterprise Manager)...This problem doesn´t seem to happen when shutting down the Tomcat server (if you didn´t undeploy before, if you did it throws a NullPointerException like this http://www.atomikos-support.com/forums/viewtopic.php?t=1296).

Perhaps with the 3.3 release all of this is solved (the shutdown hook problem).

I will wait for the 3.3 release then. Could give me some  aproximately date of release?

Thanks very very much for your help Guy. I´ll try to convince my team leaders to donate something to Atomikos...But unfortunately, in Spain there is no much community culture in software. People does not see that without solutions like this, the apps will be worse.

Regards
Juan G Send private email
Friday, April 25, 2008
 
 
Hi,

Your remarks make me think of something: are you sure that you are closing the connections so they are returned to the pool?

In particular, for every getConnection() you do, there should be a closeConnection in a finally block.

Guy
PS the approx. release of 3.3 is at May 15. We are still experiencing problems while testing so it isn't ready for GA.
Guy Pardon Send private email
Saturday, April 26, 2008
 
 
Hello Guy!

Thanks for your quick answer.

Yes, I call close() method for every getConnection() in a finally{} block.

The other day I was debugging step by step my webapp and I realised that only after the first getConnection() execution there were created 6 connections to Oracle, althought I configured the pool of TransactionEssentials with only 5.  When I undeployed the webapp it seems atomikos only closed 1 connection, so that there were 5 connections active. It´s something strange...

Thanks for the aprox. release date. I will wait for it and try again...Probably it will solve all of these problems, because all of them appeared in the forums and had the same problems like me...

Thanks very much Guy!!
Juan G Send private email
Saturday, April 26, 2008
 
 
Hi again!

I read in the examples of TransactionEssentials (examples\j2se\simple\jdbc\xadatasource\Account.java) that EVERY TIME before you get a connection the UserTransaction.begin() is invoked, even if the connection is for execute queries only (non XA transactions). Is this the normal behaviour of Atomikos T.A.? May I call ut.begin() before every getConnection statement even the connection is for non XA purposes?

I read some days ago in the atomikos documentacion (http://wiki.atomikos.org/Documentation/ConfiguringJdbc) that you could use the ut.begin and ut.commit in XA transactions, and not use it in non XA transactions. Perhaps that is the main cause of my problem, and ll have to call ut.begin before every getConnection() statement. But, if this is true, I don´t think is the correct behavior, because sometimes the UserTransaction is not needed (queries, etc). Please tell me if I´m right..

Thanks again!
Juan G Send private email
Saturday, April 26, 2008
 
 
Hi,

I found a problem in your code:

try{
    Connection con=getConnection();
      con.executeQuery....

    recursiveQuery();

}finally{
    if (con!=null){
    con.close();
}

The con in the finally is a DIFFERENT one from the one declared in the try-block. This means the finally will never close the connection gotten in the try block. This is your leak.

Best
Guy
Guy Pardon Send private email
Saturday, April 26, 2008
 
 
Hi Guy!

Sorry, as you correctly said, the connection is the same in the TRY and FINALLY block (if not, the code wouldn´t compile). I write it wrong, but in the code is correctly written (I didn´t copy-pasted)..

Thanks again Guy!
Juan G Send private email
Sunday, April 27, 2008
 
 
Hi,

I admit that I am currently out of inspiration here. If you would like more efforts then please contact sales@atomikos.com to purchase developer support, and we will invest some extra time in this.

Alternatively, you could try our 3.3.0 first (due to come out May 15).

Thanks
Guy
Guy Pardon Send private email
Saturday, May 10, 2008
 
 
Thanks Guy for the answer.

I think I will try the 3.3 version in a few days. Thanks very much for your time!

Regards,

Juan
Juan G Send private email
Monday, May 12, 2008
 
 

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics