Martin, Here's the debug from the statement cache exception: 2005-03-17 10:23:32,546 DEBUG [org.apache.ojb.broker.platforms.PlatformOracle9iImpl] PlatformOracle9iImpl could not enable Oracle statement caching. Original/unwrapped connection classes=org.jboss.resource.adapter.jdbc.WrappedConnection/oracle.jdbc.driver .OracleConnection
The code catches the exception and moves on. The managed connection doesn't have a problem with the row pre-fetch call. That method is invoked succesfully, at least in JBoss. I agree that it's probably a good idea to let the container manage that as well though, but at least it doesn't throw an exception. Thanks for getting this in a usable state for JBoss! Don -----Original Message----- From: Martin Kalén [mailto:[EMAIL PROTECTED] Sent: Thursday, March 17, 2005 3:48 AM To: OJB Users List Subject: Re: Oracle Driver jdbc10.1.0.2 Don Lyon wrote: > It looks like unwrapping the connection in initializeJdbcConnection() is > causing another problem for managed connections in JBoss. Trying to > setStatementCacheSize throws the exception: > > Caused by: java.sql.SQLException: Statement Caching cannot be enabled for > this logical connection. Hello Don, many thanks for your continous testing! > I'm not sure what the solution is. If statement caching is not allowed for > any pooled connections, maybe bypass unwrapping the Connection in this > method. Or, if it's just some managed environments that have problems, > maybe log the exception and move on instead of rethrowing PlatformException. Good catch, I thought I had already changed this - the platform should degrade linearly and not throw exceptions on failing extensions. Fixed in CVS on the 1.0.x branch now. I have added the Oracle9i platform logging setting to OJB-logging.properties so when you test again, please set the level to DEBUG once and report back the messages about connection and unwrapped connection class names. It's more costly to catch exceptions all the time than to statically try to lookup JBoss connection class through reflection once when the platform is initialized, and then not trying to set statement cache if connection is assignable from the JBoss connection class (this way we don't even need to try to unwrap the connection in initializeJdbcConnection if it's from JBoss). Also, if you could let me know the outcome of the Oracle row pre-fetch setting. Since JBoss is a managed environment it makes sence to leave both tuning parameters to the container, so my guess is that no extensions should even be tried in initializeJdbcConnection if Connection is from JBoss, BEA WebLogic etc. Regards, Martin --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] ---------------------------------- The information contained in this e-mail message is intended only for the personal and confidential use of the recipient(s) named above. If the reader of this message is not the intended recipient or an agent responsible for delivering it to the intended recipient, you are hereby notified that you have received this communication in error and that any review, dissemination, distribution, or copying of this message is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail, and delete the original message.
