|
I dont know if this is related to your problem or not, but we have are still having problems with sql handle leaks. We have verified that we always close our statements, but the sql cli traces still show handle leaks when we have sql statements with inner joins. I see up to 3 handles opened on some of our complicated sql statements. The close then only frees up 1 of the handles. The other 2 remain open and never get reused. Right now our only workaround is to restart all web instances nightly. Shahar, you could see for yourself if your problem is a handle leak by turning on the cli traces. You turn on the traces by: 1. ADDENVVAR QIBM_USRTRC_LEVEL 'INFO' 2. CHGUSRTRC JOB(XXXXXX/QTMHHTTP/YYYYYY) MAXSTG(16382) CLEAR(*YES) where xxxxxx = jobnumber of the web instance bch job yyyyyy = jobname of the web instance bch job Let the traces run for a while. Do some sql. Then create a dump of the traces with the DMPUSRTRC command (specify the same job info from step 2 above). The dump will create a file called QTEMP/QAP0ZDMP. If you look at that file you can see if the file handle numbers are growing without being reused. IBM manual SC41-5806-01 has the info on the cli commands you will see in the dump and will help you interpret the info. Alex Garrison ----- Original Message ----- From: "Luther Ananda Miller" <luther.miller@HYPERE.COM> To: <JAVA400-L@midrange.com> Sent: Tuesday, March 07, 2000 2:30 AM Subject: Re: Problem with jdbc based application > Sounds like the statements are not always being closed (even know you said > they are!). > To be 100% sure, make sure you close them in a finally clause: > stmt = connection.xxx(); > try { > ... > } finally {stmt.close(); } > > ----- Original Message ----- > From: shahar mor <shahar_mor@yahoo.com> > To: <JAVA400-L@midrange.com> > Sent: Monday, 6 March 2000 22:21 > Subject: Problem with jdbc based application > > > > Hi all, > > > > We developed client/server application using java on > > the client connecting with the java toolbox jdbc > > driver to data base on the as400. > > > > It work fine using stored procedures when needed and > > prepared statements for the sql request. > > > > BUT, sometimes upon heavy use of the system the > > QZDASOINIT joblog contains some 2000 odp in option 14, > > The joblog tells me that odp's are not deleted in > > order to "reuse" it later and in the end, on rare > > occasions i get 'reached maximum number of > > statements'. > > > > We are quite sure that statements are being closed by > > the application however, we cant get rid of this > > situation. > > > > Any suggestions/comments are most welcomed. > > > > TIA > > > > Shahar > > > > ===== > > Shahar mor > > consultant > > __________________________________________________ > > Do You Yahoo!? > > Talk to your friends online with Yahoo! Messenger. > > http://im.yahoo.com > > +--- > > | 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 > > +--- > > +--- > | 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 > +--- > +--- | 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.