Setting the PSCacheSize to 0 disables prepared statement caching in 2.4.5. Prepared statement caching is dropped in 3.0.
xxxxxxxxxxxxxxxxxxxxxxxx Scott Stark Chief Technology Officer JBoss Group, LLC xxxxxxxxxxxxxxxxxxxxxxxx ----- Original Message ----- From: "danch" <[EMAIL PROTECTED]> To: "Jeffrey Wescott" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Tuesday, May 14, 2002 2:53 PM Subject: Re: [JBoss-dev] Patch #532376 / Bug #478882 > Ah, there should definately be an option to turn that bloody feature > off. THe important part of the preparedstatement happens on the server > anyway. Oracle does its own caching of the query plans (or whatever) > involved for your PreparedStatement, as does any other database where > a prepared statement gives you any actual advantage. The only thing > this actually pools are the java objects involved, and with modern > garbage collectors that doesn't buy much. > > -danch > > Jeffrey Wescott wrote: > > > In the newly-released JBoss 2.4.5, a patch was applied (#532376) to fix bug > > #478882. The patch changes the behavior of the prepared statement pool > > (which, I believe, is used by anyone using the XA wrapper DataSourceClass) > > such that when close() is called on the prepared statement, it propogates > > that close() call to the underlying implementation object. > > > > This patch, unfortunately, has broken things for people using JBoss / Castor / > > Oracle. > > > > Below is my message to the castor-dev mailing list on the topic. > > > > ------------------------------------->8 cut here > > Here's the idea: > > In 2.4.4: > > 1- Castor obtains a PREPARED STATEMENT from the JBoss PREPARED STATEMENT pool. > > 2- Castor does work. > > 3- Castor calls STMT.close() to close the prepared statement. > > 4- JBoss returns the PREPARED STATEMENT to pool. > > > > In 2.4.5: > > 1- Castor obtains a PREPARED STATEMENT from the JBoss PREPARED STATEMENT pool. > > 2- Castor does work. > > 3- Castor calls STMT.close() to close the prepared statement. > > 4- JBoss returns the PREPARED STATEMENT to pool and closes it. > > > > I investigated this further and commenting out the lines in the close() method > > of the PreparedStatementInPool class make it work as it did in 2.4.4. > > > > if( impl != null ) > > impl.close(); > > > > It looks like this patch (#532376) was committed to fix bug #478882, but it > > seems to have caused another problem. > > > > For what it's worth, I'm using Oracle 8.x with classes12.zip. Any idea > > whether or not it does its own prepared statement pooling? Also, how do I > > turn OFF the pooling in JBoss to try to get this stuff to work WITHOUT > > changing code? > > ------------------------------------->8 cut here > > > > My questions are: > > > > 1- Was there any testing done before this patch was applied? Though this > > fixes something for people using MSSQL, it breaks something for people using > > Oracle. > > > > 2- Conceptually, is it the correct thing to do? Previously, the prepared > > statement pool just returned the object to the pool upon a call to close(). > > Now it actually closes the underlying prepared statement. What good is > > pooling a closed prepared statement? > > > > 3- As an Oracle user, is there some other way to get stuff working without > > using the XA wrapper DataSourceClass? I've tried lots of combinations or the > > OracleXADataSource class and Oracle Xid stuff, but none with any success. > > Others in the JBoss forums seem to share my woes in this regard. > > > > ++jeff > > > > P.S. -- At this point, it is not an option for me to use another technology > > besides Castor / Oracle. > > > > > > _______________________________________________________________ > > > > Have big pipes? SourceForge.net is looking for download mirrors. We supply > > the hardware. You get the recognition. Email Us: [EMAIL PROTECTED] > > _______________________________________________ > > Jboss-development mailing list > > [EMAIL PROTECTED] > > https://lists.sourceforge.net/lists/listinfo/jboss-development > > > > > > > _______________________________________________________________ > > Have big pipes? SourceForge.net is looking for download mirrors. We supply > the hardware. You get the recognition. Email Us: [EMAIL PROTECTED] > _______________________________________________ > Jboss-development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development > _______________________________________________________________ Have big pipes? SourceForge.net is looking for download mirrors. We supply the hardware. You get the recognition. Email Us: [EMAIL PROTECTED] _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
