|
Alex -- Do you see a downside to asking IBM to enhance the releaseIBMConnection() method to call Statement.close() on any open statements? Seems like if you assumed it would work that way, others will too. I don't see any justification for keeping the Statement alive so it seems like the method should work as you first assumed. It sort of beats having hard-to-diagnose handle leaks for no good reason. Did you have any discussions with IBM in this direction? Gary > Alex Garrison wrote: > > We recently had an interesting problem that took some help from > Rochester to pinpoint: > > After several days of uptime, jdbc accross all web server instances > in websphere would suddenly stop working. All subsequent sql queries > would fail, even those from interactive green-screen sessions. Our > only recovery would be to end and restart all websphere instances. > The problem seemed to happen randomly, at any time of the day or > night. We were at a loss to explain the problem. > > We sent a sql cli trace to IBM and found out that we were running out > of free sql handles. Long story short: You must call the > Statement.close() method when you are finished with a statement. If > you return a connection back to the IBM connection manager with > IBMJdbcConn.releaseIBMConnection() without closing all the statements > on the connection, you will create a sql handle leak. Eventually you > just run out of sql handles and, wham, you are stuck. We had assumed > that the connection manager would clean up everything when we called > the releaseIBMConnection() method - it does not. > > So if any of your servlets are a little sloppy about calling > Statement.close(), fix it. > > BTW: I would like to publicly thank the IBM guys that helped us nail > this problem. I would also like to mildly rebuke those at IBM gave me > a hard time declaring this a severity 1 problem (I think bringing > websphere to its knees on a dedicated e-commerce as/400 is severity > 1). > > > Alex Garrison > agarrison@logtech.com > (423)636-7213 +--- | This is the JAVA/400 Mailing List! | To submit a new message, send your mail to JAVA400-L@midrange.com. | To subscribe to this list send email to JAVA400-L-SUB@midrange.com. | To unsubscribe from this list send email to JAVA400-L-UNSUB@midrange.com. | Questions should be directed to the list owner: joe@zappie.net +---
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.