struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Murray Collingwood" <>
Subject Re: how to sustain the sanity of the connection pool
Date Tue, 11 Oct 2005 12:47:23 GMT
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("***************** Open connection=" + 
            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 -= 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, 
***************** Close connection=7

***************** Close connection=6

***************** Close connection=5

***************** Close connection=4

***************** Close connection=3

***************** Close connection=2

***************** Close connection=1

Good luck

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

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:
For additional commands, e-mail:

View raw message