|
From: Juergen H. <ju...@in...> - 2006-03-16 10:33:13
|
This is caused by Hibernate 3.1's introduction of its
"BorrowedConnectionProxy". Any Connection returned from a Hibernate =
Session
is now such a proxy instead of the target Connection. Of course our
NativeJdbcExtractor doesn't know how to deal with this, since it =
operates on
actual connection pool handles.
This is not a Spring issue in the first place, of course: It will affect =
any
code calling Session.connection() and expecting to cast it to a driver =
impl
class - or usually, first connection pool impl class, then driver impl
class.
I've just checked the Hibernate implementation of that
BorrowedConnectionProxy: There is no direct way of retrieving the =
underlying
target Connection; it's simply not been considered. This is a pain, of
course, but we can do something about it: apply the same =
DatabaseMetaData
trick that our SimpleNativeJdbcExtractor uses.
So what I've done is refined our NativeJdbcExtractorAdapter base class: =
It
first tries the subclass's extraction process. If that failed - that is,
returned the same Connection handle as passed in - we'll simply call
con.getMetaData().getConnection() and retry the subclass's extraction
process.
Since Hibernate doesn't wrap the Connection exposed by the =
DatabaseMetaData
object, we'll get access to the actual pool Connection and are able to =
apply
our C3P0 / Commons DBCP / etc extraction rules. This will also work for =
all
other sorts of simple proxying, for example by other persistence =
providers.
The NativeJdbcExtractorAdapter refinement will be released in Spring 2.0 =
M4
and also (a bit later) in Spring 1.2.8. For the time being, simply =
subclass
your extractor and call con.getMetaData().getConnection() before =
attempting
to cast for C3P0ProxyConnection (or the like).
Juergen
=20
-----Original Message-----
From: spr...@li...
[mailto:spr...@li...] On Behalf =
Of
Magnus Heino
Sent: Monday, March 13, 2006 2:01 PM
To: spr...@li...
Subject: [Springframework-developer] C3P0NativeJdbcExtractor problem =
with
Hibernate 3.1.2
Hi.
I'm not sure if this is a bug, new feature, or if it's me just being =
dumb :)
I have a class that extends JdbcDAOSupport. I'm using
com.mchange.v2.c3p0.ComboPooledDataSource,
org.springframework.orm.hibernate3.LocalSessionFactoryBean and
org.springframework.jdbc.support.nativejdbc.C3P0NativeJdbcExtractor.
I do this:
conn =3D (OracleConnection) getJdbcTemplate()
=09
.getNativeJdbcExtractor().getNativeConnection(
=09
DataSourceUtils.getConnection(getDataSource()));
in the c3p0jdbcextractor, this instanceof
protected Connection doGetNativeConnection(Connection con) throws
SQLException {
if (con instanceof C3P0ProxyConnection) {
returns true when using hibernate 3.0.5. When using 3.1.2 however, "con"
looks like this:
con=3D $Proxy19 (id=3D196)
h=3D BorrowedConnectionProxy (id=3D253)
connectionManager=3D ConnectionManager (id=3D256)
batcher=3D BatchingBatcher (id=3D261)
borrowedConnection=3D $Proxy19 (id=3D196)
callback=3D JDBCContext (id=3D265)
connection=3D NewProxyConnection (id=3D268)
factory=3D SessionFactoryImpl (id=3D269)
interceptor=3D EmptyInterceptor (id=3D275)
isClosed=3D false
releaseMode=3D ConnectionReleaseMode (id=3D278)
wasConnectionSupplied=3D false
useable=3D true
the "con" when used hibernate 3.0.5 is now in
con->h->connectionManager->connection
Is this a configuration error, hibernate bug, C3P0NativeJdbcExtractor =
bug,
or what?
--
/Magnus Heino
-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting =
language
that extends applications into web and mobile media. Attend the live =
webcast
and join the prime developer group breaking into this new coding =
territory!
http://sel.as-us.falkag.net/sel?cmd=3Dk&kid=110944&bid$1720&dat=121642
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer
|