× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.




See "4.1.5 DataSource Implementations" at:

http://java.sun.com/javase/6/docs/technotes/guides/jdbc/getstart/datasource.html#1000109

then see:

http://java.sun.com/j2se/1.4.2/docs/api/javax/sql/PooledConnection.html

If an implementation calls itself Java, then it must follow the
standards. At least it must not intentionally not follow the standard. That's a large part of what makes Java Java. Sort of like what is is.

To be direct to your question, which David has already answered: Always close at least the Connection when you're done with it. As I tried to emphasize in my JDBC 2.0 tutorial, a defensive programmer also always closes the ResultSet and the Statement as soon as you're done with them. Unless you want performance problems and possible eventual shutdown and database impact. Do not depend on finalizers for anything.


Joe Sam

Joe Sam Shirah - http://www.conceptgo.com
conceptGO - Consulting/Development/Outsourcing
Java Filter Forum: http://www.ibm.com/developerworks/java/
Just the JDBC FAQs: http://www.jguru.com/faq/JDBC
Going International? http://www.jguru.com/faq/I18N
Que Java400? http://www.jguru.com/faq/Java400

----- Original Message ----- From: "Neill Harper" <neill.harper@xxxxxxxx>
To: "'Java Programming on and around the iSeries / AS400'"
<java400-l@xxxxxxxxxxxx>
Sent: Friday, March 20, 2009 4:24 PM
Subject: RE: Should application do connection.close()?


The javadoc on the ibm site says that .close() returns the connection to
the
pool so you should deffo close it.

// Obtain an AS400JDBCConnectionPoolDataSource object from JNDI.
Context context = new InitialContext(environment);
AS400JDBCConnectionPoolDataSource datasource =
(AS400JDBCConnectionPoolDataSource)context.lookup("jdbc/myDatabase");

// Create an AS400JDBCConnectionPool object.
AS400JDBCConnectionPool pool = new AS400JDBCConnectionPool(datasource);

// Adds 10 connections to the pool that can be used by the application
(creates the physical database connections based on the data source).
pool.fill(10);

// Get a handle to a database connection from the pool.
Connection connection = pool.getConnection();

... Perform miscellenous queries/updates on the database.

// Close the connection handle to return it to the pool.
connection.close();

... Application works with some more connections from the pool.

// Close the pool to release all resources.
pool.close();

-----Original Message-----
From: java400-l-bounces@xxxxxxxxxxxx
[mailto:java400-l-bounces@xxxxxxxxxxxx]
On Behalf Of David Gibbs
Sent: 20 March 2009 19:57
To: Java Programming on and around the iSeries / AS400
Subject: Re: Should application do connection.close()?

Lim Hock-Chai wrote:
When the method does AS400JDBCConnectionPool.getConnection(), it will
return a java.sqlConnection object to the caller. I'm assuming that the
close() method of this returned Connection object is being overriden to
not close the connection. Instead, it put it back to the pool. That is
just my guess. The doc does really say anyhting about this. Can anyone
confirm?

Regardless if it returns the connection back to the pool, it's always a
good
practice to release resources you have locked. If you don't close the
connection, the server job will remain active waiting to service your job.

Just like you would close a file that you explicitly opened in RPG
(assuming
it was a usropn file).

david



As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

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.