Re: [Proxool-developer] Vendor extended connection...

[<chr...@em...>]

Having spendt most of last week working with Oracle ARRAYS I must say 
this is a most excelent suggestion :)

Sure, my code will still have to be tied to Oracle, but I can drop the 
Proxool dependency.

Its not too promiscuous regarding vendor specifics either, as users 
still have to cast to use the non conformant features.

Sun has currently 202 JDBC implementations registered:
http://servlet.java.sun.com/products/jdbc/drivers/browse_all.jsp

Maybe we should make a prioritized list and examine the most important 
implementations to look for potential pitfalls of this approach?

CHR

Bertrand Renuart wrote:

> 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()
>          
>   /**
>    * getCallWithKey Searches the explicit cache for a match on key.
>    */
>   java.sql.CallableStatement getCallWithKey(java.lang.String key)
>          
>   /**
>    * Retrieves the current setting of the createStatementAsRefCursor 
> flag which
>    * you can set with the setCreateStatementAsRefCursor method.
>    */
>   boolean getCreateStatementAsRefCursor()
>
> [...]
>  
> 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...
>  
> This is particularly true for methods to get access to BLOB/CLOB where 
> most vendors have their own may to access it.
>  
> ==> A quick solution might be to change the code so the *returned 
> proxy implements *all* interfaces implemented by the *real* connection.*
>  
> 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.
>  
> This vendor extended interface may - possibly - also give other ways 
> to close the connection - which would break everything :(
>  
>  
> Don't see any easy solution right now...
> What do you think ?
>  
>  
> BTW: saw this issue by looking at the C3P0 bug list ;) 
> (http://sourceforge.net/tracker/index.php?func=detail&aid=918628&group_id=25357&atid=383693 
> <http://sourceforge.net/tracker/index.php?func=detail&aid=918628&group_id=25357&atid=383693>)
>  
>  
> -bertrand