Another solution is to use a proxing framework (like spring), that
opens and closes the connections for you. This way you know that the
connection will always be closed after the method call, regardless if
there was an error or not.
You can also create a base class for all your actions that has a try
{} finally{ connection.close(); } statement so that your connections
are always closed. But I think the DAO pattern is probably the best if
you want to keep your actions and data access code seperate.
Also look at the commons-dbutil library, as it has a nice closeQuitly
method so you can close a connection without catch for the
IOException.
On 11/10/05, Murray Collingwood <[EMAIL PROTECTED]> wrote:
> 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]
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
