It's a while since I've used Oraclie 8i, but I think there was a discrepancy between the JDBC spec and the 8i drivers: when you close a statement it *should* close any associated ResultSet, but this didn't always work. So with Oracle, you should always explicitly close each result set, statement and connection - don't rely on the drivers to do it for you.
Regards, Al. > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of > Adrian Brock > Sent: 22 August 2003 12:03 > To: [EMAIL PROTECTED] > Subject: Re: [JBoss-user] JBoss 3.0.7 and maximum open > cursors exceeded > > > If you are closing the prepared statements that should close > the result sets. My guess is that you are not. > > Try it with 3.2.1, it has a check for unclosed statements > when you return the connection to the pool. > > Regards, > Adrian > > On Fri, 2003-08-22 at 04:17, Michael Klem wrote: > > I have code in production which is currently running on JBoss 2.4.4 > > and I finished migrating it to run under JBoss 3.0.7. It works but > > when I attempt to load test the app under JBoss 3.0.7 within 15 > > minutes I get this exception: > > ORA-01000: maximum open cursors exceeded > > > > Here is some data from my oracle-service.xml file: > > > > <depends optional-attribute-name="ManagedConnectionPool"> > > <!--embedded mbean--> > > <mbean > > > code="org.jboss.resource.connectionmanager.JBossManagedConnect > ionPool" > > name="jboss.jca:service=LocalTxPool,name=coreProvPool"> > > > > <attribute name="MinSize">20</attribute> > > <attribute name="MaxSize">40</attribute> > > <attribute name="BlockingTimeoutMillis">5000</attribute> > > <attribute name="IdleTimeoutMinutes">1</attribute> > > <!--criteria indicates if Subject (from security domain) or > > app supplied > > parameters (such as from getConnection(user, pw)) are > > used to distinguish > > connections in the pool. Choices are > > ByContainerAndApplication (use both), > > ByContainer (use Subject), > > ByApplication (use app supplied params only), > > ByNothing (all connections are equivalent, usually if > > adapter supports > > reauthentication)--> > > <attribute name="Criteria">ByContainer</attribute> > > </mbean> > > </depends> > > > > > > I can run the same stress testing code for as long as I > want when the > > app is running on JB0ss 2.4.4. The database, ( Oracle 8i ) and the > > driver, ( classes12.zip ) are used by both versions of the app. The > > code base is the same too. The only glaring difference is the JBoss > > version. > > > > My code closes the db connections and all PreparedStatements. I > > cannot see anything obvious there yet. > > > > When I get this error, I can fix it temporarily by invoking > the flush > > method on > > org.jboss.resource.connectionmanager.JBossManagedConnectionPool. > > Also, even when the exception occurs, the AvailableConnectionCount > > remains close to my MaxSize. > > > > I looked at the info from the mailing list and the forums but it > > looks like I am doing everything right. > > > > Is this a known issue under JB0ss 3.0.7? I will try using JB0ss 3.2 > > to see if it goes away. > > ------------------------------------------------------- This SF.net email is sponsored by: VM Ware With VMware you can run multiple operating systems on a single machine. WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines at the same time. Free trial click here:http://www.vmware.com/wl/offer/358/0 _______________________________________________ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user
