> -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]On Behalf Of Igor > Fedorenko > Sent: Monday, February 17, 2003 1:56 PM > To: [EMAIL PROTECTED] > Subject: RE: [JBoss-dev] jbosscx rfe 677512 > > > > -----Original Message----- > > From: Sonnek, Ryan [mailto:[EMAIL PROTECTED]] > > Sent: Monday, February 17, 2003 11:50 AM > > To: '[EMAIL PROTECTED]' > > Subject: [JBoss-dev] jbosscx rfe 677512 > > > > > > i posted this request about a week ago, and would like to know any > > developers thoughts on this. to summerize, i'd like to be > > able to force a > > datasource to timeout any connections in the pool after a > > period of time. > > > > we're running jboss 3.0.6 with oracle 8i and right now and > > we're constantly > > running into an error "Maximum number of cursors exceeded." > > being able to > > timeout connections that have been used heavily to restore > > those cursors is > > the only idea i had to get around this error. > > > > unfortunately this is a MAJOR problem for us right now, since > > we can't get > > our application up with 24/7 reliability. it only takes a > > matter of minutes > > of heavy activity to exceed 300 cursors on oracle. if there > > is some other > > way to get around this error, i would appreciate any > > feedback. or, if this > > is a planned enhancement, when would it be integrated? > > I am not sure I understand your problem. In RFE you are saying > "cached prepared statements stay alive and cause this error". > What caches prepared statements? Did you explicitly enabled > statement caching on oracle connections? > > I remember seeing this error message but it turned to be a > problem in one of my SSBs which did not explicitly close > java.sql.[Prepared]Statement. Well, strictly speaking it is a > known JBoss bug/limitation -- "Connection.close()" does not close > all opened [Prepared]Statement as it is supposed to -- but is has > a reasonable workaround. > Igor is correct. You are probably not closing your statements and/or ResultSets. You can get what sql statements are being leaked from Oracle. Backtrack in your code to find out where you are not closing your statements.
We need to implement this in the 3.x series. 2.4 already had this feature and is all around more tolerant of buggy application code. I have this on my todo list, but if anybody is willing to implement right away, let us know. Bill > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > Jboss-development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
