proxool-developer

[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

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

[Bill H. <bi...@lo...>]

Bertrand,

On Thu, 2004-03-18 at 22:13, Bertrand Renuart wrote:

> ==> A quick solution might be to change the code so the returned proxy
> implements *all* interfaces implemented by the *real* connection.

Do you know, I think that might just work...

> 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.

I'm not sure that will be a problem. We recognise that a statement has
been requested, not from the full signature, but from the return type
only. We invoke the method on the connection and if the return type is a
statement (or a subclass of statement) then we remember it.

> This vendor extended interface may - possibly - also give other ways
> to close the connection - which would break everything :(

You mean like overriding close() with close(int somethingOrOther)? Yep,
that would be awkward. I think we could ask for our users to call the
main close method, couldn't we?

> Don't see any easy solution right now...
> What do you think ?

I think it's worth investigating. Should be pretty quick to do a test
and see whether it works. I think you're going to need a JDBC driver and
a database (like Oracle) that displays this behaviour. 

If nobody else can do it any quicker I could try that out on Tuesday.

> 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)

You have your finger on the pulse, Bertrand :)

- Bill

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

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

> 
> > ==> A quick solution might be to change the code so the returned proxy 
> > implements *all* interfaces implemented by the *real* connection.
> 
> Do you know, I think that might just work...
> 

Nope... Cause before the ProxyConnection is returned to the user, it is
wrapped by another proxy (at least in the current version - don't know in
your rewite for dispoable wrapper).
This second wrapping is made by calling the following code:

    /**
     * Get a Connection from the ProxyConnection
     * 
     * @param proxyConnection where to find the connection
     * @return 
     */
    protected static Connection getConnection(ProxyConnectionIF
proxyConnection) {
        return (Connection) Proxy.newProxyInstance(
                Connection.class.getClassLoader(),
                new Class[]{Connection.class},
                (InvocationHandler) proxyConnection);
    }

So the new proxy will implement java.sql.Connection only.

BUT ...

The ProxyConnection instance held inside proxool implements *all* interface
of the *real* connection... The same stragey should be used for the one
returned to the user.

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

[Bill H. <bi...@lo...>]

Bertrand,

On Thu, 2004-03-18 at 23:44, Bertrand Renuart wrote:

> Nope... Cause before the ProxyConnection is returned to the user, it is
> wrapped by another proxy (at least in the current version - don't know in
> your rewite for dispoable wrapper).

Ah, I should have said: in *my uncommitted* code that am I just testing
then we don't double wrap and the delegate connection interfaces *are*
proxied ;)

I'm about 80% certain it will work. I'll be 100% certain when I see it
working :)

- Bill

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

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

BTW, the same remark applies to ResultSets and PreparedStatements ;)
Some vendor do enhance them as well...



> -----Original Message-----
> From: pro...@li... 
> [mailto:pro...@li...] On 
> Behalf Of Bill Horsman
> Sent: vendredi 19 mars 2004 1:00
> To: 'Proxool Developer List'
> Subject: RE: [Proxool-developer] Vendor extended connection...
> 
> 
> Bertrand,
> 
> On Thu, 2004-03-18 at 23:44, Bertrand Renuart wrote:
> 
> > Nope... Cause before the ProxyConnection is returned to the 
> user, it 
> > is wrapped by another proxy (at least in the current 
> version - don't 
> > know in your rewite for dispoable wrapper).
> 
> Ah, I should have said: in *my uncommitted* code that am I 
> just testing then we don't double wrap and the delegate 
> connection interfaces *are* proxied ;)
> 
> I'm about 80% certain it will work. I'll be 100% certain when 
> I see it working :)
> 
> - Bill
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by: IBM Linux Tutorials
> Free Linux tutorial presented by Daniel Robbins, President 
> and CEO of GenToo technologies. Learn everything from 
> fundamentals to system 
> administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
> _______________________________________________
> Proxool-developer mailing list Pro...@li...
> https://lists.sourceforge.net/lists/listinfo/proxool-developer
> 

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

[Bill H. <bi...@lo...>]

On Fri, 2004-03-19 at 09:36, Bertrand Renuart wrote:

> BTW, the same remark applies to ResultSets and PreparedStatements ;)
> Some vendor do enhance them as well...

That should be fixable too. There is this comment in the
ProxyFactory.getStatement() code:

"We can't use Class#getInterfaces since that doesn't take into account
superclass interfaces. We could, laboriously, work our way up the
hierarchy but it doesn't seem worth while - we only actually expect
three options:"

And it then goes on to either implement Statement, PreparedStatement or
CallableStatement.

I am just running some tests to see if we can do a recursive lookup of
interfaces. If that works, I will try and optimise it so that statements
that simply implement the standard JDBC spec don't need to do this
lookup. It's not hugely expensive but it does involve some recursion and
building a Set (and then converting that Set into an array).

- Bill

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