Re: JNDI DBCP Resources: Pool Leak

[netsql]

Also, nighly builds od DBCP and Pool are broken (45 bytes each for weeks).

.V

Nikola Milutinovic wrote:

Justin Jaynes wrote:


Concerning JNDI Database Connection Pooling Sources,

--
thx,
.V

roomity.com is the broadband portal 

cell: 917 825 3035 in DFW
email: netsql at roomity.com


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: JNDI DBCP Resources: Pool Leak

[Nikola Milutinovic]

Justin Jaynes wrote:


Concerning JNDI Database Connection Pooling Sources, I
have read that if you fail to explicitely close Result
Sets, Statements, or Connections to the DataSource
from WITHIN the web application, a connection in the
pool will be "lost."  (I read this at:
http://jakarta.apache.org/tomcat/tomcat-5.5-doc/jndi-datasource-examples-howto.html).

I understand that you can set an option to reclaim
"lost" connections.  That's great.

But to avoid this in the first place, I have a
question.

I have a JSP which sends Statement objects to a Bean
(not a bean by exact definition) which accesses the
database and returns a ResultSet.

The jsp code is like this:

<% com.x.DatabaseInterface web = new
com.x.DatabaseInterface(); %>
<% web.connect(); %>
<% String selectSQL = "SELECT * FROM place;"; %>
<% ResultSet result = web.selectQuery(selectSQL); %>

<% while ( result.next() ) { %>
<%= result.getString("placename") %>
<% } %>

<% web.disconnect(); %>

Of course, there are statement objects and resultset
objects in the code above.  Do I have to explicitely 
close them IN JSP AND also the ones IN THE BEAN or

just  the ones in the BEAN?  I suppose this is a
fundamental principle of Java which I do not fully
understand as the objects .  Can someone please
enlighten me?
 



Well, generally speaking, it is good practice to close/dispose_of a 
resource near the point where it is created, if it is of a transient 
nature. In your case, ResultSet, Statement and Connection are of 
transient nature, since you're not really interested in them, but in the 
data they give you.


The best way of doing it is having a bean that will take DataSource and 
"do it's stuff" with it, creating and closing what is neccessary to load 
itself with data. I used Struts in my previous project and my 
Struts-Actions were taking DataSource, handing it over to a DAO 
implementation, which was responsible for DB manipulation. Struts (and 
JSP) saw nothing of that.


In your case, yes, you should close the connection, at least. Actually, 
you should close RS, St and then Connection, in that particular order.


Nix.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

JNDI DBCP Resources: Pool Leak

[Justin Jaynes]

Concerning JNDI Database Connection Pooling Sources, I
have read that if you fail to explicitely close Result
Sets, Statements, or Connections to the DataSource
from WITHIN the web application, a connection in the
pool will be "lost."  (I read this at:
http://jakarta.apache.org/tomcat/tomcat-5.5-doc/jndi-datasource-examples-howto.html).

I understand that you can set an option to reclaim
"lost" connections.  That's great.

But to avoid this in the first place, I have a
question.

I have a JSP which sends Statement objects to a Bean
(not a bean by exact definition) which accesses the
database and returns a ResultSet.

The jsp code is like this:

<% com.x.DatabaseInterface web = new
com.x.DatabaseInterface(); %>
<% web.connect(); %>
<% String selectSQL = "SELECT * FROM place;"; %>
<% ResultSet result = web.selectQuery(selectSQL); %>

<% while ( result.next() ) { %>
<%= result.getString("placename") %>
<% } %>

<% web.disconnect(); %>

Of course, there are statement objects and resultset
objects in the code above.  Do I have to explicitely 
close them IN JSP AND also the ones IN THE BEAN or
just  the ones in the BEAN?  I suppose this is a
fundamental principle of Java which I do not fully
understand as the objects .  Can someone please
enlighten me?

The Bean looks like this:

package com.;

import java.sql.*;
import javax.sql.*;
import java.io.*;
import javax.naming.InitialContext;
import javax.naming.Context;

public class DatabaseInterface {

String error;

DataSource ;


Connection database;
ResultSet result;
Statement select;
Statement update;

public DatabaseInterface() { }

public void connect() throws Exception {
try {
InitialContext initContext = new InitialContext();
 = (DataSource)
initContext.lookup("java:comp/env/jdbc/");
database = .getConnection();
} catch (Exception e) {
error = "Data Source Opening Connection Error: " +
e;
throw new Exception(error);
}
}

public void disconnect() throws Exception {
try {

database.close();
} catch (Exception e) {
error = "Data Source Closing Connection Error: " +
e;
throw new Exception(error);
}

}

public ResultSet selectQuery(String webStatement)
throws SQLException, Exception {
try {
if ( database != null) {
select = database.createStatement();
result = select.executeQuery(webStatement);
}
} catch (SQLException sqle) {
error = "SQL Error Disconnecting: " + sqle;
throw new SQLException(error);
} catch (Exception e) {
error = "Error in selectQuery block:" + e;
throw new Exception(e);
}
return result;
}

public void insertQuery(String webStatement) throws
SQLException, Exception {
try {
if ( database != null) {
update = database.createStatement();
update.execute(webStatement);
}
} catch (SQLException sqle) {
error = "SQL Error: " + sqle;
throw new SQLException(error);
} catch (Exception e) {
error = "Error in insertQuery block:" + e;
throw new Exception(e);
}
}
}





__
Click here to donate to the Hurricane Katrina relief effort.
http://store.yahoo.com/redcross-donate3/

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]