proxool-developer — Developer's discussion list

Re: [Proxool-developer] Driver specific interfaces

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

I hate to be the devils advocate here... but maybe we can find a more 
simple and generic way of doing this?

How about evaluating a full blown AOP approach instead? That is: We do 
not use proxies anomore, but simply  intercept the  methods  we  need to 
handle specially.

This will prevent us from using the disposable wrapper though (i think)...

CHR



Bill Horsman wrote:

>On Wed, 2004-03-24 at 21:41, Christian Nedregård wrote:
>
>  
>
>>Phrooh!
>>    
>>
>
>!
>
>  
>
>>Why do you consider tying your code  to a self-produced interface tied
>>to the currently exposed methods of a vendor spesific class to be more
>>robust and maintainable than tying your code to a ProxoolFacade
>>method?
>>    
>>
>
>That's not the point. By exposing the real connection people can really
>easily call close() or prepareStatement() directly. (In fact, they are
>quite likely to build Statements directly). Calling close() directly
>loses the connection forever. Building a Statement that Proxool doesn't
>know about stops Proxool resetting the connection correctly when it is
>returned to the pool. 
>
>  
>
>>Using Proxool facade saves you both the writing/maintaining of the
>>interface and the extra configration.
>>    
>>
>
>I agree with you there. I'm cautious about the extra work involved. 
>
>And I agree that tying your code to a self-written interface rather than
>the Oracle (or whatever) class is no better.
>
>- 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_id70&alloc_id638&op=click
>_______________________________________________
>Proxool-developer mailing list
>Pro...@li...
>https://lists.sourceforge.net/lists/listinfo/proxool-developer
>
>  
>

RE: [Proxool-developer] Driver specific interfaces

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

> That's not the point. By exposing the real connection people=20
> can really easily call close() or prepareStatement()=20
> directly. (In fact, they are quite likely to build Statements=20
> directly). Calling close() directly loses the connection=20
> forever. Building a Statement that Proxool doesn't know about=20
> stops Proxool resetting the connection correctly when it is=20
> returned to the pool.=20
>=20

That's it - and I think everybody will agree.


> > Using Proxool facade saves you both the writing/maintaining of the=20
> > interface and the extra configration.
>=20
> I agree with you there. I'm cautious about the extra work involved.=20
>=20
> And I agree that tying your code to a self-written interface=20
> rather than the Oracle (or whatever) class is no better.
>=20

I cannot agree with either statements ;)

What are we trying to solve?
We want to give people a way to access vendor specific extensions =
without
giving them the *real* connection.
As we said, this is not a problem if the vendor driver is coded against =
an
interface.
The problem is when the *real* connection is a concrete class, without
interface.

Conclusion: the user wants to use the extra features - so he becomes =
tied to
this particular driver. And he will have to maintain his code as the =
vendor
changes his interface.

______________
First Solution

The *real* connection is available via the ProxoolFacade. The usage =
scenario
becomes:

	1/ Connection c =3D DriverManager.getConnection();
	2/ com.vendor.VendorConnection vc =3D (com.vendor.VendorConnection)
ProxoolFacade.getRealConnection(c);
	3/ call vc.vendorSpecificMethod();

-> you explcitlity depends on Proxool
-> you explicitly introduce the Vendor class everywhere in your code
(casting)
-> you get the *real* connection

_______________
Second Solution

1/ Define your own interface that mimics the VendorConnection (entirely =
or a
subset):

	public interface VendorConnectionIF extends java.sql.Connection {
	   void vendorSpecificMethod();
	}

   (no need to define those you will not use)


2/ Inject this method in Proxool configuration

   <proxool>
     <alias>my-oracle-pool</alias>
     <driver-url>jdbc:oracle...</driver-url>
     <driver-class>oracle.jdbc.OracleDriver</driver-class>
     <connection-interface>
       yourpackage.VendorConnection
     </connection-interface>
   </proxool>


3/ Then use it

	1/ yourpackage.VendorConnection c =3D
(yourpackage.VendorConnection)DriverManager.getConnection();
	2/ call vc.vendorSpecificMethod();

-> you don't explicitly depend on Proxool (except in your configuration)
-> you are casting to an interface of your own (your own package - does =
it
matter ?)
-> you don't get the real connection

You still have to maintain your VendorConnectionIF interface in synch =
with
the signature of the Vendor driver - same overhead as solution 1.


___________
Conclusion:

I don't see any particular overhead for the user - same problem for both
solutions.
The user doesn't have access to the *real* connection.
For Proxool, the overhead is only to maintain the configuration code, =
the
injection of the user-supplied interface in the proxy is already part of =
the
creation of the dispoable wrapper...


-bertrand

RE: [Proxool-developer] Driver specific interfaces

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

On Wed, 2004-03-24 at 21:33, Bertrand Renuart wrote:

> Except, to be easy to use, the StrangeConnectionIF should somehow extend
> java.sql.Connection - otherwise the guy will have to recast all the time -
> but this is up to him to sort it out ;-)

Good point for documentation though.

> BUT, you then have to be carefull when building your proxy because you may
> have several interfaces to implement that extend the same parent
> (java.sql.Connection) - not sure it is a problem...

It isn't.

> And we should also include the following extensions:
> 
>      <resultset-interface>
>        com.outside.jdbc.StrangeResultSetIF
>      </resultset-interface>

Not needed. We don't proxy the ResultSet. At least, not yet.

>      <statement-interface>
>        com.outside.jdbc.StrangeStatementIF
>      </statement-interface>

And PreparedStatement and CallableStatement.

- Bill

Re: [Proxool-developer] Driver specific interfaces

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

On Wed, 2004-03-24 at 21:41, Christian Nedreg=E5rd wrote:

> Phrooh!

!

> Why do you consider tying your code  to a self-produced interface tied
> to the currently exposed methods of a vendor spesific class to be more
> robust and maintainable than tying your code to a ProxoolFacade
> method?

That's not the point. By exposing the real connection people can really
easily call close() or prepareStatement() directly. (In fact, they are
quite likely to build Statements directly). Calling close() directly
loses the connection forever. Building a Statement that Proxool doesn't
know about stops Proxool resetting the connection correctly when it is
returned to the pool.=20

> Using Proxool facade saves you both the writing/maintaining of the
> interface and the extra configration.

I agree with you there. I'm cautious about the extra work involved.=20

And I agree that tying your code to a self-written interface rather than
the Oracle (or whatever) class is no better.

- Bill

Re: [Proxool-developer] Driver specific interfaces

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

Phrooh!

Why do you consider tying your code  to a self-produced interface tied 
to the currently exposed methods of a vendor spesific class to be more 
robust and maintainable than tying your code to a ProxoolFacade method?

Using Proxool facade saves you both the writing/maintaining of the 
interface and the extra configration.


CHR

Bill Horsman wrote:

>Bertrand,
>
>On Wed, 2004-03-24 at 21:12, Bertrand Renuart wrote:
>
>  
>
>>You point to another (easier) solution: the ability for people to *inject*
>>interfaces in our proxy class.
>>
>>They could define an interface containing the signature of the methods they
>>want from the vendor jdbc connection (rs and st as well); then register this
>>extra interface with proxool.
>>    
>>
>
>1.
>  <proxool>
>    <alias>my-oracle-pool</alias>
>    <driver-url>jdbc:oracle...</driver-url>
>    <driver-class>oracle.jdbc.OracleDriver</driver-class>
>    <connection-interface>
>      com.outside.jdbc.StrangeConnectionIF
>    </connection-interface>
>  </proxool>
>
>2.
>  public interface StrangeConnectionIF {
>    public void foo();
>  }
>
>3.
>  Connection c = DriverManager.getConnection(url, properties);
>  StrangeConnectionIF sc = (StrangeConnectionIF) c;
>  sc.foo();
>
>Like that?
>
>- 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] Driver specific interfaces

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

> Bertrand,
>=20
> On Wed, 2004-03-24 at 21:12, Bertrand Renuart wrote:
>=20
> > You point to another (easier) solution: the ability for people to=20
> > *inject* interfaces in our proxy class.
> >=20
> > They could define an interface containing the signature of=20
> the methods=20
> > they want from the vendor jdbc connection (rs and st as well); then=20
> > register this extra interface with proxool.
>=20
> 1.
>   <proxool>
>     <alias>my-oracle-pool</alias>
>     <driver-url>jdbc:oracle...</driver-url>
>     <driver-class>oracle.jdbc.OracleDriver</driver-class>
>     <connection-interface>
>       com.outside.jdbc.StrangeConnectionIF
>     </connection-interface>
>   </proxool>
>=20
> 2.
>   public interface StrangeConnectionIF {
>     public void foo();
>   }
>=20
> 3.
>   Connection c =3D DriverManager.getConnection(url, properties);
>   StrangeConnectionIF sc =3D (StrangeConnectionIF) c;
>   sc.foo();
>=20
> Like that?
>=20

Yes, something like that. Would be cool, no?

Except, to be easy to use, the StrangeConnectionIF should somehow extend
java.sql.Connection - otherwise the guy will have to recast all the time =
-
but this is up to him to sort it out ;-)

BUT, you then have to be carefull when building your proxy because you =
may
have several interfaces to implement that extend the same parent
(java.sql.Connection) - not sure it is a problem...

And we should also include the following extensions:

     <resultset-interface>
       com.outside.jdbc.StrangeResultSetIF
     </resultset-interface>
     <statement-interface>
       com.outside.jdbc.StrangeStatementIF
     </statement-interface>

In any case, if this is not enough - remains the ConnectionBuilder =
extension
point (which is working btw)...
Proxool becomes more and more open ;)


Remark:
I'm +100K in favor of the two solutions described in this thread rather =
than
exposing the *real* connection to the user...

RE: [Proxool-developer] Driver specific interfaces

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

Bertrand,

On Wed, 2004-03-24 at 21:12, Bertrand Renuart wrote:

> You point to another (easier) solution: the ability for people to *inject*
> interfaces in our proxy class.
> 
> They could define an interface containing the signature of the methods they
> want from the vendor jdbc connection (rs and st as well); then register this
> extra interface with proxool.

1.
  <proxool>
    <alias>my-oracle-pool</alias>
    <driver-url>jdbc:oracle...</driver-url>
    <driver-class>oracle.jdbc.OracleDriver</driver-class>
    <connection-interface>
      com.outside.jdbc.StrangeConnectionIF
    </connection-interface>
  </proxool>

2.
  public interface StrangeConnectionIF {
    public void foo();
  }

3.
  Connection c = DriverManager.getConnection(url, properties);
  StrangeConnectionIF sc = (StrangeConnectionIF) c;
  sc.foo();

Like that?

- Bill

RE: [Proxool-developer] Driver specific interfaces

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

> > The pluggable ConnectionBuilder I was talking about last time may=20
> > provide a solution. If required, people could build their own=20
> > connection builder. This builder would return an adapter around the=20
> > vendor supplied connection.
>=20
> I see that might be possible. But writing an adapter is not a=20
> trivial task. And they would have to maintain it across JDK versions.
>=20
As you say *they* would have to maintain it... Not the proxool team!
Anyway, this workaround would be for drivers not implementing interfaces =
and
people wanting to access their special features...


> I suppose they could provide just the interface and we could=20
> include that in out proxy class... No adapter needed. Just=20
> their own interface that matches the API of the driver's=20
> Connection object. I wonder whether that would work.
>=20
You point to another (easier) solution: the ability for people to =
*inject*
interfaces in our proxy class.

They could define an interface containing the signature of the methods =
they
want from the vendor jdbc connection (rs and st as well); then register =
this
extra interface with proxool.

When building the proxy, you would add these extra interfaces to the
proxy...

RE: [Proxool-developer] Driver specific interfaces

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

Bertrand,

On Wed, 2004-03-24 at 15:05, Bertrand Renuart wrote:

> The pluggable ConnectionBuilder I was talking about last time may provide a
> solution.
> If required, people could build their own connection builder. This builder
> would return an adapter around the vendor supplied connection. 

I see that might be possible. But writing an adapter is not a trivial
task. And they would have to maintain it across JDK versions.

I suppose they could provide just the interface and we could include
that in out proxy class... No adapter needed. Just their own interface
that matches the API of the driver's Connection object. I wonder whether
that would work.

- Bill

RE: [Proxool-developer] Driver specific interfaces

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

> > Oooh. Moving up the social hierachy of metaphores are we ;)
>=20
> I'm moving up yes. But I'm not so proud that I won't still=20
> speak to you. I'll still remember you when I'm famous :)
>=20

Can't follow you anympore :(

> > I'm convinced...  But please do not focus on this as a *grand* new=20
> > feature when we release. Its a good idea I agree, but vendor=20
> > flabbiness will lead to a lot of dissapointed and confused users.=20
> > Agreed?
>=20
> Agreed.
>=20

You know what ?

The pluggable ConnectionBuilder I was talking about last time may =
provide a
solution.
If required, people could build their own connection builder. This =
builder
would return an adapter around the vendor supplied connection. If this
adapter implements an interface, then it would become =
available/implemented
by Bill's disposable wrapper...

This way, the recommended approach to get access to functionalities =
exposed
by the *real* connection would be:
- if your real connection implements an Interface, then just cast the
proxool-connection to that interface;
- if not - shame on your vendor! - build your own ConnectionBuilder...

The ...getConnection() returning the *real* connection could then be =
dropped
(safer!)

?

-bertrand

Re: [Proxool-developer] Driver specific interfaces

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

CHR,

On Wed, 2004-03-24 at 14:41, Christian Nedreg=E5rd wrote:

> Oooh. Moving up the social hierachy of metaphores are we ;)

I'm moving up yes. But I'm not so proud that I won't still speak to you.
I'll still remember you when I'm famous :)

> I'm convinced...  But please do not focus on this as a *grand* new
> feature when we release. Its a good idea I agree, but vendor
> flabbiness will lead to a lot of dissapointed and confused users.
> Agreed?

Agreed.

- Bill

Re: [Proxool-developer] Driver specific interfaces

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

>It's a golfing reference :) It means "what you would expect".
>
>  
>

Oooh. Moving up the social hierachy of metaphores are we ;)

>>It means that the cast might work when you are using one version of
>>the Oracle driver, and then break when you change driver version, wich
>>will be extremely confusing to the user.
>>    
>>
>
>Is it true that later versions use interfaces and earlier versions
>don't? If so, then I think it is fine. 
>  
>

Probably.

>>It's flabby (something that might work with a particular driver
>>version from a few of the vendors). I don't like flabby, but I won't
>>veto this either.
>>    
>>
>
>I prefer to think of the drivers as flabby :) I think they should write
>their APIs to interfaces.
>  
>

Aiight!

I'm convinced...  But please do not focus on this as a *grand* new 
feature when we release. Its a good idea I agree, but vendor flabbiness 
will lead to a lot of dissapointed and confused users. Agreed?

CHR

Re: [Proxool-developer] Driver specific interfaces

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

Hi,

On Wed, 2004-03-24 at 12:31, Christian Nedreg=E5rd wrote:

> > Sounds par for the course.

> Eh? You've reached the borders of my understanding of English mate ;)

It's a golfing reference :) It means "what you would expect".

> It means that the cast might work when you are using one version of
> the Oracle driver, and then break when you change driver version, wich
> will be extremely confusing to the user.

Is it true that later versions use interfaces and earlier versions
don't? If so, then I think it is fine.=20

> It's flabby (something that might work with a particular driver
> version from a few of the vendors). I don't like flabby, but I won't
> veto this either.

I prefer to think of the drivers as flabby :) I think they should write
their APIs to interfaces.

But it would require some FAQ entries. Like:

Q - Why can't I cast the Connection to an OracleConnection?

A - You need to upgrade to version 8.x.y or later.

Or if we felt like being a bit more general:

Q - Why can't I cast the Connection to an XyzConnection?

A - Proxool's Connection only implements public interfaces provided by
the driver. If XyzConnection isn't an interface then you can't cast it.

- Bill

Re: [Proxool-developer] Driver specific interfaces

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

Bill Horsman wrote:

>CHR,
>
>On Wed, 2004-03-24 at 09:44, Christian Nedreg=E5rd wrote:
>
> =20
>
>>A quick check on interface based JDBC implementations:
>>SQLServer: No
>>Sybase: Yes
>>postgreSQL: Yes
>>MySQL: No
>>DB2: No
>>   =20
>>
>
>What does that mean? A "no" means that the driver doesn't implement any
>driver specific interfaces?
>
> =20
>

It means that the implementations of Connection, Statement etc. does not=20
implement any vendor spesific interfaces.

>>...and then you have Oracle. Here the confusion is complete
>>   =20
>>
>
>Sounds par for the course.
>
> =20
>

Eh? You've reached the borders of my understanding of English mate ;)

>>We should certantly NOT deprecate DriverManager.getConnection and
>>friends.=20
>>   =20
>>
>
>Eh? How can we deprecate a JDK method? I'm confused.=20
>
>
> =20
>

Sorry. I meant ProxoolFacade.getDelegateConnection().

>>I am very uncertain wether this stuff is going to add value or
>>confusion. Please consider this again
>>   =20
>>
>
>It won't do any harm. If a public interface for the object is available
>it will be used. If it isn't then it behaves like it did before.
>
> =20
>
>>By the way; your example below won't work with the Oracle driver we
>>use (8.1.7.0.4).=20
>>OracleConnection is a class there...
>>   =20
>>
>
>Hmm. Well that's a shame. But just to be clear, it will "work" in as
>much as Proxool will behave itself. It just means that the cast won't
>work and you'll have to use ProxoolFacade.getDelegateConnection(). Which
>is probably what you meant.
> =20
>

It means that the cast might work when you are using one version of the=20
Oracle driver, and then break when you change driver version, wich will=20
be extremely confusing to the user.

>In summary: I think that exposing the public interfaces is still a good
>idea. It won't be as useful as I originally thought because not all
>drivers use public interfaces, but it's certainly a step forwards.
>
>
> =20
>

It's flabby (something that might work with a particular driver version=20
from a few of the vendors). I don't like flabby, but I won't veto this=20
either.

CHR

>
>-------------------------------------------------------
>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_id638&op=3Dclick
>_______________________________________________
>Proxool-developer mailing list
>Pro...@li...
>https://lists.sourceforge.net/lists/listinfo/proxool-developer
>
> =20
>

Re: [Proxool-developer] Driver specific interfaces

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

CHR,

On Wed, 2004-03-24 at 09:44, Christian Nedreg=E5rd wrote:

> A quick check on interface based JDBC implementations:
> SQLServer: No
> Sybase: Yes
> postgreSQL: Yes
> MySQL: No
> DB2: No

What does that mean? A "no" means that the driver doesn't implement any
driver specific interfaces?

> ...and then you have Oracle. Here the confusion is complete

Sounds par for the course.

> We should certantly NOT deprecate DriverManager.getConnection and
> friends.=20

Eh? How can we deprecate a JDK method? I'm confused.=20

I did mention deprecating ProxoolFacade.getDelegateConnection() and
getDelegateStatement(). From what you say below that is probably not a
good idea.

> I am very uncertain wether this stuff is going to add value or
> confusion. Please consider this again

It won't do any harm. If a public interface for the object is available
it will be used. If it isn't then it behaves like it did before.

> By the way; your example below won't work with the Oracle driver we
> use (8.1.7.0.4).=20
> OracleConnection is a class there...

Hmm. Well that's a shame. But just to be clear, it will "work" in as
much as Proxool will behave itself. It just means that the cast won't
work and you'll have to use ProxoolFacade.getDelegateConnection(). Which
is probably what you meant.

In summary: I think that exposing the public interfaces is still a good
idea. It won't be as useful as I originally thought because not all
drivers use public interfaces, but it's certainly a step forwards.

- Bill

Re: [Proxool-developer] Driver specific interfaces

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

Oh.
I might have been a bit naive to the usability of this :(

A quick check on interface based JDBC implementations:
SQLServer: No
Sybase: Yes
postgreSQL: Yes
MySQL: No
DB2: No

...and then you have Oracle. Here the confusion is complete, with 
definitions changing from version to version from class to interface 
etc. In some versions interfaces from the "internal" package is used, in 
some versions not.

We should certantly NOT deprecate DriverManager.getConnection and friends.

I am very uncertain wether this stuff is going to add value or 
confusion. Please consider this again.

By the way; your example below won't work with the Oracle driver we use 
(8.1.7.0.4).

OracleConnection is a class there...

CHR



Bill Horsman wrote:

>Hi all,
>
>Just an update for everyone. Following Bertrand's recommendation, I've
>changed the ProxyFactory so that when we proxy a connection or a
>statement we also implement the same public interfaces as the original
>object. The upshot of this is that you can now do:
>
>  Connection c = DriverManager.getConnection(url, properties);
>  OracleConnection oc = (OracleConnection) c;
>
>This means we can probably deprecate the old
>ProxoolFacade.getDelegateConnection and getDelegateStatement methods. I
>say "probably" because the new proxy solution only works for interfaces.
>All well written drivers should be written to interfaces but if anyone
>is using a connection object that provides public methods that aren't
>declared in an interface then they won't be accessible. I'm tempted to
>live with that limitation.
>
>Remember, exposing the delegate connection is a weakness since it allows
>people to close the delegate instead of the proxy thereby not returning
>it to the pool.
>
>All this is uncommitted at the moment. Committing very soon.
>
>- 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
>
>  
>

[Proxool-developer] Driver specific interfaces

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

Hi all,

Just an update for everyone. Following Bertrand's recommendation, I've
changed the ProxyFactory so that when we proxy a connection or a
statement we also implement the same public interfaces as the original
object. The upshot of this is that you can now do:

  Connection c = DriverManager.getConnection(url, properties);
  OracleConnection oc = (OracleConnection) c;

This means we can probably deprecate the old
ProxoolFacade.getDelegateConnection and getDelegateStatement methods. I
say "probably" because the new proxy solution only works for interfaces.
All well written drivers should be written to interfaces but if anyone
is using a connection object that provides public methods that aren't
declared in an interface then they won't be accessible. I'm tempted to
live with that limitation.

Remember, exposing the delegate connection is a weakness since it allows
people to close the delegate instead of the proxy thereby not returning
it to the pool.

All this is uncommitted at the moment. Committing very soon.

- Bill

[Proxool-developer] Proxool-doc changes

[Nathanael U. <no...@no...>]

Hi all

I've added Docbook Website templates to proxool-doc.

Any website-specific stuff is placed in src/website, most notably
layout.xml, which is the file describing the website sitemap.

Running ant generate.website will produce HTML files in build/website.

Also note that you need Ant 1.6 and that resolver.jar needs to be on
your classpath (or put into ant_home/lib, otherwise Ant's <xmlcatalog>
tag won't work).  Is this acceptable, or should we write the buildfile
in such a way that it will be included?

It's starting to look like a site that we might like to use.  Templates
just need a bit more work.

Nat

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

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

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

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

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

[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