[Proxool-developer] Vendor extended connection...

[Bertrand R. <ber...@mo...>]

Dear all,


New feature proposal... again ;)
I'll make it short, just consider the following :

[...]

/**
 * This interface defines the Oracle extensions to the standard JDBC
interface
 * java.sql.Connection. You can use java.sql.Connection in your =
application
 * where you do not make use of the Oracle extensions. However, when =
your
 * application uses the Oracle extensions to java.sql.Connection you =
must
use
 * oracle.jdbc.OracleConnection.
 * OracleConnection extends standard JDBC connection functionality to =
create
 * and return Oracle statement objects, set flags and options for Oracle
 * performance extensions, and support type maps for Oracle objects.
 */
public abstract interface OracleConnection extends java.sql.Connection
{
  /**
   * The driver is always in auto-close mode.
   */
  boolean getAutoClose()
        =20
  /**
   * getCallWithKey Searches the explicit cache for a match on key.
   */
  java.sql.CallableStatement getCallWithKey(java.lang.String key)
        =20
  /**
   * Retrieves the current setting of the createStatementAsRefCursor =
flag
which
   * you can set with the setCreateStatementAsRefCursor method.
   */
  boolean getCreateStatementAsRefCursor()

[...]

=20
Do you see my point ?
Currently, Proxool will return a proxy implementing java.sql.Connection =
-
meaning extra features provided by the *real* connection won't be =
available
to the user...
=20
This is particularly true for methods to get access to BLOB/CLOB where =
most
vendors have their own may to access it.
=20
=3D=3D> A quick solution might be to change the code so the returned =
proxy
implements *all* interfaces implemented by the *real* connection.
=20
BUT (as usual there is a but) - this may not be safe in all cases... The
OracleConnection above provides extra methods to return resources bind =
to
the connection - a CallableStatement or PreparedStatement for example.
Proxool will not be aware of this resource and won't be able to release =
them
as it already do for PreparedStatement/ResultSet returned through the
standard java.sql.Connection interface.
=20
This vendor extended interface may - possibly - also give other ways to
close the connection - which would break everything :(
=20
=20
Don't see any easy solution right now...
What do you think ?
=20
=20
BTW: saw this issue by looking at the C3P0 bug list ;)
(http://sourceforge.net/tracker/index.php?func=3Ddetail
<http://sourceforge.net/tracker/index.php?func=3Ddetail&aid=3D918628&grou=
p_id=3D25
357&atid=3D383693> &aid=3D918628&group_id=3D25357&atid=3D383693)
=20
=20
-bertrand