I found out that there is the method getInnermostDelegate() on the DBCP DelegatingPreparedStatement calling this will return the original PreparedStatement independently on how many hierarchies of wrappers DBCP is using.
That's perfectly right -- yesterday I added a recursive generic unwrap-function to the default Oracle9i platform that will try to unwrap Connection and PreparedStatement objects until and Oracle-compatible class is found.
Current implementation knows about Oracle10g, Commons DBCP, P6Spy and BEA WebLogic.
It's easy to add new methods to the array of known names/argument types.
So for the first time ever the Oracle9i platform could handle large CLOB and BLOB using both P6Spy and DBCP (which will render the Connection "superwrapped" in multiple wrappers).
There is a problem with using Oracle and the default DBCP connection factory, since PreparedStatement caching in DBCP will "eat" all your Oracle cursors rather quickly. See the release notes for a work-around (set PSPoolFactory==null). In OJB 1.1 the configuration mechanism will be a bit more flexible so you will probably not see any new connection factories in the 1.0.x line of releases.
Another issue is the "accesToUnderlyingConnection" in DBCP which can stop the large LOB-support from working. This will also not be set explicitly in 1.0.x since that requires a new connection factory impl or hardcoding a new configuration attribute. In OJB1.1 a generic name/value-approach till make it easier to pass implementation-specific parameters to the connection factories. However, I made some testing with the shipped DBCP v1.1 and I was able to unwrap the Connection by default (which has not been the case with previous versions).
Ok I didn't think at the runtime dependencies, following code uses reflection and avoids these external dependencies (maybe you already implemented it like this)
PreparedStatement innerPS;
try
{
Method delgGetter = ClassHelper.getMethod( ps, "getInnermostDelegate", null );
innerPS = ( delgGetter != null ) ? (PreparedStatement) delgGetter.invoke( ps, null ) : ps;
} catch ( Exception ignore ) {
innerPS = ps;
}
Yes, that's pretty much exactly how the code in CVS looks now (although the method name/type are parametrized to try multiple options).
Testing of the new functionality is appreciated; either check out from CVS on OJB_1_0_RELEASE branch or wait a few days until OJB1.0.2 is released. (Vote has already passed, we are just holding off while investigating an issue in the ODMG.)
Regards, Martin
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
