A pertinent question, had the same problem myself this afternoon.
I use Tomcat DBCP and found that each connection really does need to be closed.
If
you don't your pool of connections is quickly depleted.
>From the many code samples I have looked at (not that many really) I find many
>people
extend the MVC concept to MVCD where D is the "DAO" or Data Access Object. In
my
recent app I have declared a Dao class that provides by abstract database class
and
then defined all my databases to use this Dao super class. I then have
standard
functions in the Dao class for managing my connections. The connections
themselves
all come from a function in my persistence class (like a Manager.class with a
getInstance() function).
Finally I can put println() calls in my persistence class to count the usage.
This is of
course very manual, maybe somebody has a better method. What would be nice is
if
Tomcat had some monitor for the connection pool that we could watch....probably
need
to direct that question to the Tomcat list.
Visually my stuff looks like the following:
public class Manager {
private static Manager manager = new Manager();
public Manager getInstance() {
return manager;
}
public Connection getConnection() {
return dataSource.getConnection();
}
...a few other methods to support the above...
}
public class Dao {
/** Creates a new instance of Dao */
public Dao() {
try {
Manager.getInstance().connections += 1;
System.err.println("");
System.err.println("***************** Open connection=" +
Manager.getInstance().connections);
connection = Manager.getInstance().getConnection();
if (connection == null)
System.err.println("ERROR: Dao: Failed to establish connection
== null");
} catch (Exception e) {
System.err.println("ERROR: Dao: " + e.getMessage());
}
}
public void close() {
try {
if (rs != null) rs.close();
if (statement != null) statement.close();
if (connection != null) connection.close();
} catch (Exception e) {
System.err.println("ERROR: Dao: " + e.getMessage());
}
System.err.println("***************** Close connection=" +
Manager.getInstance().connections);
System.err.println("");
Manager.getInstance().connections -= 1;
}
...lots of other methods to do stuff to the database...
}
As you can see in the above two methods I have implemented a counter, this
serves to
write to the log the number of connections in use at any one time. The count
of course
goes up and down as I move from page to page, but at the end of any page being
posted it should continually return to zero.
As in this output:
***************** Open connection=1
***************** Open connection=2
***************** Open connection=3
***************** Open connection=4
***************** Open connection=5
***************** Open connection=6
***************** Open connection=7
SQL: SELECT itid, icid, stocode, sloname, stoname, scontent, iduckrank, irank,
iduration, simagename, ddateStart, ddateStop FROM Tour WHERE itid = '3' LIMIT
0,
50
***************** Close connection=7
***************** Close connection=6
***************** Close connection=5
***************** Close connection=4
***************** Close connection=3
***************** Close connection=2
***************** Close connection=1
Good luck
mc
On 11 Oct 2005 at 15:02, emre akbas wrote:
> Hi,
> I have some general questions about connection pooling and exception
> handling.
> Struts suggests that developers use declarative exception handling. In
> declarative exception handling, there are almost no "try { } catch() {}"
> blocks in the Action classes. Exception occuring in Action classes are
> handled by exception handlers outside the Action classes. Everything seems
> OK so far.
> It is very usual that we open a connection to the database at the beginning
> of the Action class and then close it at the end. When an exception occurs,
> an exception-handler outside of our Action class (in which the exception is
> thrown) handles the exception. Then, what happens to the connection? We
> weren't able to close it, so does it continue to allocate a connection from
> the pool?
> My other question is about the connection pooling itself. Are there any
> tools or ideas to monitor the sanity of the connection pool? Are we somehow
> able to find the classes where leakage occur?
> Thanks in advance.
>
FOCUS Computing
Mob: 0415 24 26 24
[EMAIL PROTECTED]
http://www.focus-computing.com.au
--
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.344 / Virus Database: 267.11.13/124 - Release Date: 7/10/2005
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
