commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hope, Matthew" <Matthew.H...@capitalone.com>
Subject RE: DBCP exception; very hard to debug
Date Mon, 28 Apr 2003 16:57:54 GMT
For that you need a whole treatise on encapsulation and its use within
application tiering.

Model View Controller is just one methodolgy / framework / idiom that
assists in encapsulation at a higher level than just making a variable
private.

The idea is to break up:

Your Model (underlying structure of your data as well as how that maps to
it's persitant store such as a database)

Your View (how you present this data either to a user or to another
application exposed for example by SOAP)

Your Controller (Logic for what to do given user actions etc)

(this is very fast and loose - for a better description look on the web)

If you wish to change something to do with one of the M, V or C the
interfaces between these three should be so well defined that the change
either has little knock on effect. Either because a level of abstraction
sufficient to work around the change is already present or that the change
is centralised and easy to cascade back down it's calling chain. If however
three different jsp's all access one table then making a change to the table
could cause some bizarre knockon effects and cause an uncontrolled cascade
of changes through your code. Speaking from experience on this from having
seen it the effects of this done a couple of times on a large code base can
be pretty horrific to support and maintain.

Other things that become tricky is performance optimisations. If you
centralise access to an expensive resource putting an indirection layer
allows much easier insertion of caching behaviour and/or entirely changing
how the data is stored.

It's just one aspect of the might OnceAndOnlyOnce which for me is a decent
goal to aspire to whether you're an XP coder or not.

Matt Hope

-----Original Message-----
From: Brian Menke [mailto:brian@innovtech.com] 
Sent: 28 April 2003 17:19
To: Tomcat Users List; Jakarta Commons Users List
Subject: RE: DBCP exception; very hard to debug


Whoops, this statement left me curious since I do this.

Accessing databases directly from a JSP page too ... sheesh :-).

Craig

Could you please give a semi newbee (less than 3 years java coding
experience) information on why this is bad? And better yet, a better way to
do this?

Thanks!

-Brian

-----Original Message-----
From: Craig R. McClanahan [mailto:craigmcc@apache.org]
Sent: Monday, April 28, 2003 9:05 AM
To: Jakarta Commons Users List
Cc: tomcat-user@jakarta.apache.org
Subject: Re: DBCP exception; very hard to debug




On Mon, 28 Apr 2003, Charles So wrote:

> Date: Mon, 28 Apr 2003 13:35:07 +0800
> From: Charles So <charles_so@mac.com>
> Reply-To: Jakarta Commons Users List <commons-user@jakarta.apache.org>
> To: tomcat-user@jakarta.apache.org, commons-user@jakarta.apache.org
> Subject: DBCP exception; very hard to debug
>
> Hello,
>
> I am using DBCP 1.0 with Tomcat 4.1.24. The other Apache Commons I am
> using with DBCP1.0 are:
>
> commons-collections2.1.jar
> commons-logging-api.103.jar
> commons-pool.101.jar
>
>
>
> The webapp I am writing is set to have a maximum of 40 sessions. The
> allowed maximum number of connection to MySQL is 210. The minimum
> number of idle connection is set to 100 at Tomcat level.
>
> Each session uses 5 connections to start doing its work.
>

This is not a very good design for using connection pools (you should
design your apps so that they do not keep connections allocated in between
requests), but that is not the fundamental problem here.

> The first time I stress my webapp all is fine. I can see 40 sessions
> all used up in Tomcat's Manager.
>
> I then wait until all sessions to time out and stress it again. This
> time it is usually OK too.
>
> However, the 3rd time it is very likely to have thrown *tons* of this
> exception:
>
>
>
> DBCP borrowObject failed: java.sql.SQLException: Server connection
> failure during transaction.
> Attemtped reconnect 3 times. Giving up.
> Exception in Item org.apache.commons.dbcp.DbcpException:
> java.sql.SQLException: Server connection failure during transaction.
> Attemtped reconnect 3 times. Giving up.
>
>
>
> It seems that some objects are not released by DBCP. All 100
> connections shown in MySQL are idle.

The most likely cause for this is that the app neglects to return
connections to DBCP (often because an SQLException causes your code to
skip the release path).  This is not DBCP's problem.

>
>
> I tried using the nightly snapshot of DBCP, with all the above other
> commons. It is even worse. The webapp cannot even run the first time!
>
> It would complain:
>
> org.apache.jasper.JasperException:
> org.apache.commons.pool.impl.GenericObjectPool: method ()V not found

That means you've got an old version of commons-pool.jar or
commons-dbcp.jar around someplace, or you've got them installed in more
than one place in the class loader hierarchy.

It could also mean you didn't upgrade to the latest nightly build of
commons-pool (which the latest nightly build of commons-dbcp needs).


>          at
> org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.ja
> va:254)

Accessing databases directly from a JSP page too ... sheesh :-).

Craig

---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org
 
**************************************************************************
The information transmitted herewith is sensitive information intended only
for use by the individual or entity to which it is addressed. If the reader
of this message is not the intended recipient, you are hereby notified that
any review, retransmission, dissemination, distribution, copying or other
use of, or taking of any action in reliance upon this information is
strictly prohibited. If you have received this communication in error,
please contact the sender and delete the material from your computer.

Mime
View raw message