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