| View previous topic :: View next topic |
| Author |
Message |
pm Guest
|
Posted: Thu Dec 02, 2004 3:55 am Post subject: PreparedStatement close() function's location |
|
|
hi,
Is it necessary to wirte "oPs.close();oRs.close();" in try{} and
catch{} when I have written them in "finally{}".
Just like this:
PreparedStatement oPs;
ResultSet oRs;
public HashMap queryLatestInvoiceNo(HashMap mapValue)
{
...
try
{
...
-> oPs.close();
-> oRs.close();
}
catch()
{
-> oPs.close();
-> oRs.close();
}
finally
{
-> try{oPs.close();}
catch(){...}
-> try{oRs.close();}
catch(){...}
}
}
|
|
| Back to top |
|
 |
Joe Weinstein Guest
|
Posted: Thu Dec 02, 2004 5:12 am Post subject: Re: PreparedStatement close() function's location |
|
|
pm wrote:
| Quote: | hi,
Is it necessary to wirte "oPs.close();oRs.close();" in try{} and
catch{} when I have written them in "finally{}".
Just like this:
|
No.
Here's what I'd recommend:
myMainJdbcMethod()
{
Connection c = null; // JDBC objects are safest as method-level objecta
PreparedStatement p = null;
ResultSet r = null;
try
{
c = ...; // get connection
p = c.prepareStatement(...); // get statement
r = p.executeQuery();
....
r.close(); // close result set asap
r = null;
p.close(); // close statement asap
p = null;
c.close(); // close connection asap
c = null;
}
catch (Exception e)
{
... do whatever... catch block may not be needed
}
finally
{
// take care of failure exit paths. close all jdbc objects
// without fail.
if (r != null) try {r.close();} catch (Exception ignore){}
if (p != null) try {p.close();} catch (Exception ignore){}
if (c != null) try {c.close();} catch (Exception ignore){}
}
}
| Quote: |
PreparedStatement oPs;
ResultSet oRs;
public HashMap queryLatestInvoiceNo(HashMap mapValue)
{
...
try
{
...
-> oPs.close();
-> oRs.close();
}
catch()
{
-> oPs.close();
-> oRs.close();
}
finally
{
-> try{oPs.close();}
catch(){...}
-> try{oRs.close();}
catch(){...}
}
}
|
|
|
| Back to top |
|
 |
Robert Klemme Guest
|
Posted: Thu Dec 02, 2004 12:30 pm Post subject: Re: PreparedStatement close() function's location |
|
|
"Joe Weinstein" <joeNOSPAM (AT) bea (DOT) com> schrieb im Newsbeitrag
news:41AEA44C.7030907 (AT) bea (DOT) com...
| Quote: | pm wrote:
hi,
Is it necessary to wirte "oPs.close();oRs.close();" in try{} and
catch{} when I have written them in "finally{}".
Just like this:
No.
Here's what I'd recommend:
|
I prefer this:
myMainJdbcMethod() throws SQLException
{
Connection c = getConnection();
try {
PreparedStatement p = c.prepareStatement(...); // get statement
try {
ResultSet r = p.executeQuery();
try {
while ( r.next() ) {
// read current record
}
}
finally {
close( r );
}
}
finally {
close( p );
}
}
finally {
returnConnection( c );
}
static void close(Statement s) {
try {
s.close();
}
catch ( SQLExcetpion ignore ) {
// ignore
}
}
static void close(ResultSet r) {
try {
r.close();
}
catch ( SQLExcetpion ignore ) {
// ignore
}
}
Kind regards
robert
|
|
| Back to top |
|
 |
Joe Weinstein Guest
|
Posted: Thu Dec 02, 2004 4:00 pm Post subject: Re: PreparedStatement close() function's location |
|
|
Robert Klemme wrote:
| Quote: | "Joe Weinstein" <joeNOSPAM (AT) bea (DOT) com> schrieb im Newsbeitrag
news:41AEA44C.7030907 (AT) bea (DOT) com...
pm wrote:
hi,
Is it necessary to wirte "oPs.close();oRs.close();" in try{} and
catch{} when I have written them in "finally{}".
Just like this:
No.
Here's what I'd recommend:
I prefer this:
|
Hi, and thanks. I've seen some people do this. We're doing about the same thing...
For my taste, I don't see the benefit of creating and going to the the extra close(x)
methods that simply call x.close(). I assume your returnConnection() method also just
calls close().
Joe Weinstein at BEA
| Quote: | myMainJdbcMethod() throws SQLException
{
Connection c = getConnection();
try {
PreparedStatement p = c.prepareStatement(...); // get statement
try {
ResultSet r = p.executeQuery();
try {
while ( r.next() ) {
// read current record
}
}
finally {
close( r );
}
}
finally {
close( p );
}
}
finally {
returnConnection( c );
}
static void close(Statement s) {
try {
s.close();
}
catch ( SQLExcetpion ignore ) {
// ignore
}
}
static void close(ResultSet r) {
try {
r.close();
}
catch ( SQLExcetpion ignore ) {
// ignore
}
}
Kind regards
robert
|
|
|
| Back to top |
|
 |
Robert Klemme Guest
|
Posted: Fri Dec 03, 2004 12:12 pm Post subject: Re: PreparedStatement close() function's location |
|
|
"Joe Weinstein" <joeNOSPAM (AT) bea (DOT) com> schrieb im Newsbeitrag
news:41af3c6d$1 (AT) news (DOT) beasys.com...
| Quote: |
Robert Klemme wrote:
"Joe Weinstein" <joeNOSPAM (AT) bea (DOT) com> schrieb im Newsbeitrag
news:41AEA44C.7030907 (AT) bea (DOT) com...
pm wrote:
hi,
Is it necessary to wirte "oPs.close();oRs.close();" in try{} and
catch{} when I have written them in "finally{}".
Just like this:
No.
Here's what I'd recommend:
I prefer this:
Hi, and thanks. I've seen some people do this.
|
I'm glad you said that. )
| Quote: | We're doing about the same thing...
|
Yep, with mainly differences in style.
| Quote: | For my taste, I don't see the benefit of creating and going to the the
extra close(x)
methods that simply call x.close().
|
The benefit is that you you don't clutter your finally blocks with try {
x.close(); } catch (SQLException e) {}. Also I prefer separate
try{}finally{} blocks because then you don't have to do the null
assignments and checks. It feels cleaner and increases locality of
variables slightly, which I prefer for documentation reasons.
Indentation is not such a problem here because most methods get their
connection as argument thusly enable transaction cotrol outside methods
that do the real work. That leaves us with an additional level of
indentation vs. your solution which is bearable IMHO.
Dunno about performance impacts. Usually db stuff takes an order of
magnitude longer than the cost of finally so that'd be okay.
| Quote: | I assume your returnConnection() method also just
calls close().
|
Nah, not always: we're using a pool here so getConnection() and
returnConnection() talk to the pool. I know that could be done
differently but the solution has grown over time and it works fine so far.
Cheers
robert
|
|
| Back to top |
|
 |
|