You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by da...@quantumretail.com on 2007/03/14 00:13:02 UTC

getInnerMostDelegate returns null after 24+ hours

Hello all -
 
Before anyone jumps the gun - we've had an application running in production
for the last several months so this isn't the usual issue with
"setAccessToUnderlyingConnectionAllowed".  
 
The issue is transient - occurring sometimes after 24+ hours operation and
seem to have started after our customer's IS team applied a daylight savings
patch (and some security patches) to their server last week.   The obvious
solution to back out these changes is not an option (so I'm told).  I'm
wondering if anyone has experienced this issue before and has a work around.
Here's the code causing the problem:
 
   conn = OracleDAOFactory.createConnection();  
   Connection dconn = ((DelegatingConnection) conn).getInnermostDelegate();
---
 
[The code for createConnection is below for reference.]
 
This body of code is executed in the top of many of our DAL methods... for
some reason it seems that the native connection that we get via
getInnermostDelegate returns null.   Againt the problem doesn't happen right
away BUT we are pretty sure that once it shows up it doesn't go away
(perhaps the result of associating our statements with caching).  You will
note that we do ((BasicDataSource)
ds).setAccessToUnderlyingConnectionAllowed(true).  Also we've done a
complete code review and we are certain that we NEVER close the dconn -
rather we are always closing the parent connection.  We've also checked to
be sure that we never close a connection twice... 
 
If anyone has ideas on how configuration or code could be wrong it would be
greatly appreciated.  Another challenge here is that we don't seem to be
able to reproduce this problem outside of the production environment.  In
production (as mentioned) this manifests after 24+ hours of successful
operation.  The current (painful) workaround is to bring down the tomcat
server and bring it back up.
 
We are considering adding a check to the code on the dconn - when the dconn
is null fetch another and remove the offending connection from the pool.
Has anyone had to implement such a thing before?  If we take this approach
is there any clean way to discard that connection so that it is not reused?
I have a current prototype that removes it from the pool if the delegate is
null and never "closes" it again so that it would effectively be removed
from operation but eventually the DB Pool will recycle these "abandond"
connections... or worse - we'll run out. 
 
Any help is greatly appreciated.
 
Thanks in advance,
-Darrin F. Edelman
 
 
 
--- code for createConnection ---
 
  public static Connection createConnection() throws Exception {
    final Context initContext = new InitialContext();
    final Context envContext = (Context)
initContext.lookup("java:/comp/env");
    final DataSource ds = (DataSource) envContext.lookup("jdbc/ar");
 
    if (ds == null) {
      throw new Exception("Error: No DataSource");
    }
    Connection conn;
    ((BasicDataSource) ds).setAccessToUnderlyingConnectionAllowed(true);
    conn = ds.getConnection();
 
    return conn;
  }