|
It is always best practice to: resultSet.close(); preparedStatement.close(); connection.close(); I had a problem with file locks and it was because I was just closing the connection and not the result set and prepared statement. Don't count on the system closing your ResultSet and PreparedStatement. Richard Dettinger [cujo@us.ibm.com] set me straight on that one (see his comments below). Thanx, PLA The CLI and the QSQSRVR jobs are probably working as designed. My guess is that the SQL cursors are being left open. The system is able to release locks and process the CL command if the QSQSRVR only has pseudo-open cursors. By pseudo-open, I mean that you have closed the result set, but the system has kept it open for performance reasons. I'm thinking that my code is not attempting to close ResultSets to clean up anything when objects are returned to the pool. Although in a quick look through the code I didn't see conclusively what happens (I'm in class the next several days and very overwhelmed right now). If the result set is truly left open, then the locks on that object can't be removed by the system until they are explicitely released. Richard D. Dettinger AS/400 Java Data Access Team Democracy's enemies have always underestimated the courage of the American people. It was true at Concord Bridge. It was true at Pearl Harbor. And it was true today. Rochester Post-Bulletin Tuesday September 11, 2001 "Patrick L Archibald" <Patrick.Archibald@HOMETELCO.COM> on 01/14/2002 09:43:47 AM To: Richard Dettinger/Rochester/IBM@IBMUS cc: Subject: File locks Hi Richard When using statement and connection pooling, shouldn't the AS/400 release locks on files when the CLRPFM or DLTF commands are issued on the locked files? I have found that the QSQSRVR job will not release the file for clearing. If this is a bug I'll report it to software support. I just thought I'd ask you first. Thanx, PLA / / Patrick L Archibald / http://HomeTelco.com/pla/ / -----Original Message----- From: java400-l-admin@midrange.com [mailto:java400-l-admin@midrange.com]On Behalf Of Fred Kulack Sent: Tuesday, October 08, 2002 10:28 AM To: java400-l@midrange.com Subject: RE: Relationship between JDBC Connections, Statements, ResultSets and open data paths On 10/08/2002 at 02:45:46 AM, java400-l-admin@midrange.com wrote: > If you close the ResultSet, the Statement remains open (as does the > Connection). If you close the Statement (without > closing the ResultSet) The Statement is closed but the Connection is still open > and the ResultSet object still has scope. I'm just curious - how does it correspond to the statement from JDBC documentation (interface java.sql.ResultSet, method close()): "A ResultSet object is automatically closed by the Statement object that generated it when that Statement object is closed, re-executed, or is used to retrieve the next result from a sequence of multiple results. A ResultSet object is also automatically closed when it is garbage collected." Does it mean IBM goes its own way here? :) --- end of excerpt --- If you close the statement, its ResultSet(s) is/are closed. "The stuff we call "software" is not like anything that human society is used to thinking about. Software is something like a machine, and something like mathematics, and something like language, and something like thought, and art, and information... but software is not in fact any of those other things." Bruce Sterling - The Hacker Crackdown Fred A. Kulack - IBM eServer iSeries - Enterprise Application Solutions ERP, Java DB2 access, Jdbc, JTA, etc... IBM in Rochester, MN (Phone: 507.253.5982 T/L 553-5982) mailto:kulack@us.ibm.com Personal: mailto:kulack@magnaspeed.net AIM Home:FKulack AIM Work:FKulackWrk MSN Work: fakulack@hotmail.com _______________________________________________ This is the Java Programming on and around the iSeries / AS400 (JAVA400-L) mailing list To post a message email: JAVA400-L@midrange.com To subscribe, unsubscribe, or change list options, visit: http://lists.midrange.com/cgi-bin/listinfo/java400-l or email: JAVA400-L-request@midrange.com Before posting, please take a moment to review the archives at http://archive.midrange.com/java400-l.
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.