File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
The moose likes Tomcat and the fly likes AccessToUnderlying Connection Settings Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login

Win a copy of Java Interview Guide this week in the Jobs Discussion forum!
JavaRanch » Java Forums » Products » Tomcat
Bookmark "AccessToUnderlying Connection Settings" Watch "AccessToUnderlying Connection Settings" New topic

AccessToUnderlying Connection Settings

Balakrishnan Nagarajan

Joined: Jan 16, 2009
Posts: 20
Dear All,

I am having one issue with the tomcat server when casting the tomcat.dbcp connection to Oracle connection.

The code looks like:

Connection conn = ds.getConnection();
OracleConnection underlyingConnection = null;
Connection dconn = (OracleConnection) ((DelegatingConnection) conn).getInnermostDelegate();

Here it will throws the Classcast exception (org.apache.tomcat.dbcp.dbcp **** to Oracle Connection)

The DelegatingConnection is from Tomcat DBCP jar.
I am using Tomcat 6.0.29 and 6.0.37.

When i googled, i got to know adding the parameter accessToUnderlyingConnection=True in Datasource fixes the problem. And it works as well.

But the site says,

Default is false, it is a potential dangerous operation and misbehaving programs can do harmfull things. (closing the underlying or continue using it when the guarded connection is already closed) Be carefull and only use when you need direct access to driver specific extentions.

NOTE: Do not close the underlying connection, only the original one.

Hence the fix which i proposed got rejected.

Tried with the different Tomcat version - 6.0.20, this Casting is working fine without adding any parameters in the XML files.

Could anyone help to clarify this?

Why it is working in 6.0.20 and not in 6.0.29 version?
And how to fix this issue in 6.0.29 version as well?

Bala N.

Bala N.
Tim Holloway
Saloon Keeper

Joined: Jun 25, 2001
Posts: 17423

Most likely, it "worked" in 6.0.20 because of a bug that got fixed by release 6.0.29.

The whole reason for the rigamarole about Underlying Connection is because the actual JDBC Connection object that links to the Oracle server is not what gets returned from the connection pool. Instead what you get is a delegating extension class that mostly hands off all its method calls to the underlying (Oracle) Connection, except for the "close()" method, which simply returns the connection to the pool instead of actually severing the network linkage as the underlying Connection's close() method would.

There is really only one reason for obtaining the underlying Connection object, and that is so you can invoke methods that the underlying Connection object's driver provides that are not in the Java JDBC standards. While this can be useful, it is not something you want to do for trivial purposes. It locks you into a specific vendor, both in terms of the actual code, and in terms of where you can get support. Unless you absolutely, positively must, I don't recommend tying yourself to any vendor, even one as well-established as Oracle. You can never tell when someone in Accounting will balk at sending Larry Ellison another $100K and require you to dump your application on a PostgreSQL server instead, for example.

An IDE is no substitute for an Intelligent Developer.
I agree. Here's the link:
subject: AccessToUnderlying Connection Settings
It's not a secret anymore!