om Orielly) and then make your
changes on the top of that.
Regards,
Chandrashekhar.
-Original Message-
From: Lenin Lakshminarayanan -X (lelakshm - HCL at Cisco)
[mailto:[EMAIL PROTECTED]
Sent: Wednesday, April 05, 2006 11:45 PM
To: Tomcat Users List
Subject: RE: need inputs on conne
When starting a new thread (ie sending a message to the list about a
new topic) please do not reply to an existing message and change the
subject line. To many of the list archiving services and mail clients
used by list subscribers this makes your new message appear as part
of the old thread. Thi
You'll have to release the connection to the pool and _NOT_ close the
connection. It's something like this :
* Create a resource pool that maintains the pool
* release the resource from the pool upon request ( if the
resource Is already there in the pool and can be utilized )
Then you need to check your Driver and see what level of JDBC it is
implementing for a complete answer.
-Original Message-
From: Abh N [mailto:[EMAIL PROTECTED]
Sent: Wednesday, April 05, 2006 11:27 AM
To: Tomcat Users List
Subject: RE: need inputs on connection pool
Thanks Marc.
I
Thanks Marc.
I was reading an article
http://java.sun.com/developer/technicalArticles/J2EE/pooling/
it says with con.close() the connection will be released to connection pool
in jdbc 2.0 , in 1.0 it will be closed with the stmt.
"Farrow, Marc" <[EMAIL PROTECTED]> wrote:
Calling close() on a pooled connection simply returns it to the pool,
however, i have seen some cases where calling ti twice closes it for
real. Don't do that.
If you are interested in other options that eliminate that concern,
you may want to try iBATIS - you would still use SQL, but it manages
t
It is always good practice to call the close methods on the Connection,
Statement, PreparedStatement, ResultSet objects (if you use them). Depending
on the connection pooling that you are using, they may or may not get
released in a timely manner (for example, timeouts/etc). By explicitly
calling
