Bug 65932 - PreparedStatement 'getConnection' returns physical connection instead of pooled one
Summary: PreparedStatement 'getConnection' returns physical connection instead of pool...
Status: RESOLVED DUPLICATE of bug 48392
Alias: None
Product: Tomcat Modules
Classification: Unclassified
Component: jdbc-pool (show other bugs)
Version: unspecified
Hardware: All All
: P2 normal (vote)
Target Milestone: ---
Assignee: Tomcat Developers Mailing List
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2022-03-04 18:54 UTC by Alexey Kutishchev
Modified: 2022-03-07 23:50 UTC (History)
0 users


Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Alexey Kutishchev 2022-03-04 18:54:25 UTC 
[NOT A CONTRIBUTION]


JDBC Pool Version: 9.0.49
Database: Oracle
JDBC Version:  19.3.0.0
OS: Mac, Linux

prepareStatement created by ProxyConnection returns underlying physical connection  not the PooledConnection.

Step to reproduce:
ConnectionPool pool = ...
Connection c = pool.getConnection();
PreparedStatement ps = c.createPreparedStatement();

assertTrue(c == ps.getConnection()) // return false
Comment 1 Keiichi Fujino 2022-03-06 12:47:43 UTC 
Have you set org.apache.tomcat.jdbc.pool.interceptor.StatementDecoratorInterceptor?

This interceptor is available for prevents access to the actual connection.

see
https://tomcat.apache.org/tomcat-9.0-doc/jdbc-pool.html#org.apache.tomcat.jdbc.pool.interceptor.StatementDecoratorInterceptor
Comment 2 Alexey Kutishchev 2022-03-07 19:08:11 UTC 
That helped.

I'm surprised to see that it is not a default behavior.

Any plans to change this?
Comment 3 Christopher Schultz 2022-03-07 19:30:44 UTC 
It's probably a performance consideration NOT to wrap the connections returned by Statement.getConnection().

Do you find different behavior if you use Tomcat's default database connection pool (the one based upon commons DBCP2)?
Comment 4 Alexey Kutishchev 2022-03-07 23:50:14 UTC 
Closing this as a duplicated.

*** This bug has been marked as a duplicate of bug 48392 ***