You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Charles So <ch...@mac.com> on 2003/04/28 07:35:07 UTC
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.
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.
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
at
org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.ja
va:254)
at
org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:295)
at
org.apache.jasper.servlet.JspServlet.service(JspServlet.java:241)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Applica
tionFilterChain.java:247)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilt
erChain.java:193)
at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValv
e.java:256)
at
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.i
nvokeNext(StandardPipeline.java:643)
at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:4
80)
at
org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValv
e.java:191)
at
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.i
nvokeNext(StandardPipeline.java:643)
at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:4
80)
at
org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
at
org.apache.catalina.core.StandardContext.invoke(StandardContext.java:241
5)
at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java
:180)
at
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.i
nvokeNext(StandardPipeline.java:643)
at
org.apache.catalina.valves.ErrorDispatcherValve.invoke(ErrorDispatcherVa
lve.java:171)
at
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.i
nvokeNext(StandardPipeline.java:641)
at
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java
:172)
at
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.i
nvokeNext(StandardPipeline.java:641)
at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:4
80)
at
org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.
java:174)
at
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.i
nvokeNext(StandardPipeline.java:643)
at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:4
80)
at
org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
at
org.apache.coyote.tomcat4.CoyoteAdapter.service(CoyoteAdapter.java:223)
at
org.apache.jk.server.JkCoyoteHandler.invoke(JkCoyoteHandler.java:261)
at
org.apache.jk.common.HandlerRequest.invoke(HandlerRequest.java:360)
at
org.apache.jk.common.ChannelSocket.invoke(ChannelSocket.java:604)
at
org.apache.jk.common.ChannelSocket.processConnection(ChannelSocket.java:
562)
at
org.apache.jk.common.SocketConnection.runIt(ChannelSocket.java:679)
at
org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool
.java:619)
at java.lang.Thread.run(Thread.java:491)
root cause
javax.servlet.ServletException:
org.apache.commons.pool.impl.GenericObjectPool: method ()V not found
at
org.apache.jasper.runtime.PageContextImpl.handlePageException(PageContex
tImpl.java:536)
at org.apache.jsp.Index_jsp._jspService(Index_jsp.java:69)
at
org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:137)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
at
org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.ja
va:210)
at
org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:295)
at
org.apache.jasper.servlet.JspServlet.service(JspServlet.java:241)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Applica
tionFilterChain.java:247)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilt
erChain.java:193)
at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValv
e.java:256)
at
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.i
nvokeNext(StandardPipeline.java:643)
at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:4
80)
at
org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValv
e.java:191)
at
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.i
nvokeNext(StandardPipeline.java:643)
at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:4
80)
at
org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
at
org.apache.catalina.core.StandardContext.invoke(StandardContext.java:241
5)
at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java
:180)
at
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.i
nvokeNext(StandardPipeline.java:643)
at
org.apache.catalina.valves.ErrorDispatcherValve.invoke(ErrorDispatcherVa
lve.java:171)
at
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.i
nvokeNext(StandardPipeline.java:641)
at
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java
:172)
at
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.i
nvokeNext(StandardPipeline.java:641)
at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:4
80)
at
org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.
java:174)
at
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.i
nvokeNext(StandardPipeline.java:643)
at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:4
80)
at
org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
at
org.apache.coyote.tomcat4.CoyoteAdapter.service(CoyoteAdapter.java:223)
at
org.apache.jk.server.JkCoyoteHandler.invoke(JkCoyoteHandler.java:261)
at
org.apache.jk.common.HandlerRequest.invoke(HandlerRequest.java:360)
at
org.apache.jk.common.ChannelSocket.invoke(ChannelSocket.java:604)
at
org.apache.jk.common.ChannelSocket.processConnection(ChannelSocket.java:
562)
at
org.apache.jk.common.SocketConnection.runIt(ChannelSocket.java:679)
at
org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool
.java:619)
at java.lang.Thread.run(Thread.java:491)
Just to make sure the JVM is not the bottleneck, I set it to have:
-hotspot -Xms128m -Xmx=550m upon starting
And I have set the system (MacOSX 10.2.5 running JVM 1.3.1) to have the
following parameters:
cputime unlimited
filesize unlimited
datasize 24576 kbytes
stacksize 8192 kbytes
coredumpsize 0 kbytes
memoryuse unlimited
descriptors 1024
memorylocked unlimited
maxproc 200
The numbered values are increased either 4 times or 3 times to the
values shown above.
Please help me with DBCP!!!!
Re: DBCP exception; very hard to debug
Posted by Charles So <ch...@mac.com>.
Thanks alot Craig,
I must clarify a number of things:
1) upon finishing using a connection, each section of the code releases
the connection immediately. The current design of the webapp is
a) opens connection at the beginning
b) do numerous PreparedStatement and ResultSet based on the connection
opened at line a)
c) when all database access is done, close the connection
d) do other tasks
Are you recommending that I should do connection.close() right after
each ResultSet is used? The connection in a) is declared as a method
variable
2) all exceptions are caught, and there is no exception either from SQL
or the app itself
3) OK, I am not using the nightly built of commons-pools. will try that
4) no, the jsp pages never access the database
5) I have checked many times, there is only a single copy of each
Commons inside Tomcat's directories
I'll check 1) again... and inspect where I might made mistakes.
In order for me to understand my problem, I am curious as to where in
my statement indicates this part of your reply:
>
> 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.
>
DBCP 1.0 has no known bugs? Mark Matthew of Connector/J said he
experience relatively bad stability with DBCP1.0 when compared to DBCP
nightly built
Thanks!!!
Charles
On Tuesday, April 29, 2003, at 12:05 AM, Craig R. McClanahan wrote:
>
>
> On Mon, 28 Apr 2003, Charles So wrote:
>
>> Date: Mon, 28 Apr 2003 13:35:07 +0800
>> From: Charles So <ch...@mac.com>
>> Reply-To: Jakarta Commons Users List <co...@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: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
Re: DBCP exception; very hard to debug
Posted by Charles So <ch...@mac.com>.
Hello,
I think I have finally figured out what's wrong with the set up.
The 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.
is most likely to occur after I have made changes to the code (either
JSP file or servlet). Please see message included below.
Currently I restarted TC (still using the same configuration and the
same source code), DIDN'T RE-COMPILE THE SERVLETS NOR MAKE CHANGES TO
JSP FILES and repeated the actions >5 times trying to trigger the
exception. No luck thus far! :-)
Although it is still at early stage... I'm still repeating the steps.
I am putting my fingers crossed.
Thanks to everyone who helped me, especially Craig! Hope someone might
benefit from this.
On Tuesday, April 29, 2003, at 12:05 AM, Craig R. McClanahan wrote:
>
>
> On Mon, 28 Apr 2003, Charles So wrote:
>
>> Date: Mon, 28 Apr 2003 13:35:07 +0800
>> From: Charles So <ch...@mac.com>
>> Reply-To: Jakarta Commons Users List <co...@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
>
Re: DBCP exception; very hard to debug
Posted by Todd Grigsby <to...@tgrigsby.com>.
Mind if I wade into this discussion?
> * You'd never store allocated connections in a user's
> session -- indeed, highly scalable applications do not
> use sessions at all, or only store the minimal amount
> of state information required, in order to minimize
> memory space usage.
So given that, what's your take on the display taglib?
(http://edhill.its.uiowa.edu/display-examples/) I'm in the process of using
this taglib to display rows in a grid. I would have to read the database,
create a list of records, and keep that list in the session for navigation
purposes. The best solution I have for this is to keep a list of record IDs
(long integers, primary key) rather than the whole record, and retrieve
displayed rows on each subsequent call. But large results sets could still be
requested, and this solution would require the use of sessions.
Any thoughts on a better approach? Are sessions then unavoidable?
Todd
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
RE: DBCP exception; very hard to debug
Posted by Brian Menke <br...@innovtech.com>.
Wow! Thanks for the detailed explanation. It makes great sense. I guess
release 2 of the app I'm doing will attempt to use these practices.
Thanks!!
-Brian
-----Original Message-----
From: Craig R. McClanahan [mailto:craigmcc@apache.org]
Sent: Monday, April 28, 2003 9:52 AM
To: Jakarta Commons Users List
Cc: Tomcat Users List
Subject: RE: DBCP exception; very hard to debug
On Mon, 28 Apr 2003, Brian Menke wrote:
> Date: Mon, 28 Apr 2003 09:19:08 -0700
> From: Brian Menke <br...@innovtech.com>
> Reply-To: Jakarta Commons Users List <co...@jakarta.apache.org>
> To: Tomcat Users List <to...@jakarta.apache.org>,
> Jakarta Commons Users List <co...@jakarta.apache.org>
> 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!
>
Sure.
Many beginning web application developers -- especially if you came from
an ASP or PHP background -- start out by lumping the logic to create the
user interface of their page, and the logic to process form submits and
update the database, into the same source file. This works ok for small
scale apps (if I were writing a guestbook type app, i'd certainly do it
this way), but doesn't scale well to large complex apps.
In those environments, you really want to have a "separation of concerns"
between the presentation tier (how does the UI get created) and the
business tier (how does the database get updated), so that you can
maintain and enhance them independently. Further, proper architecture
lets you reuse the same business logic in non-webapp programs that perform
the same tasks (say that you've got logic to update a customer, and you
need it in both an interactive webapp, and a batch processing program, and
a web service).
In the Java world, a number of application frameworks have become popular
to help app developers deal with this sort of thing, by applying
principles from the Model View Controller (MVC) design pattern first made
popular in writing interactive GUI apps. The most popular Java based
framework is Struts (disclaimer -- I'm the original author :-):
http://jakarta.apache.org/struts/
But no matter what you use for architecting the business logic of your
webapp, I would also encourage you to do some research on design patterns
for dealing with the database. I will shoot anyone who tries to take my
copy of "Core J2EE Patterns" by Alur, Crupi, and Malks -- there's lots of
good advice there even if you are not using EJBs -- but there are other
sources as well. Struts, for example, is fundamentally an implementation
of the "Front Controller" pattern described in this book (with lots of
other goodies).
A typical web application architected on good design patterns would
exhibit the following characteristics with respect to the database:
* You'd typically only use one connection per request
(allocating it at the beginning, making it available
as needed, then returning it to the pool) or one
connection per business function (if you hide the
use of the pool inside the persistence tier classes),
unlike your scenario of having 5.
* You'd never store allocated connections in a user's
session -- indeed, highly scalable applications do not
use sessions at all, or only store the minimal amount
of state information required, in order to minimize
memory space usage.
* The net effect of the above is that, if your database
can support X simultaneous transactions, you can support
X simultaneous HTTP requests -- but the number of active
users who have an ongoing session can be a much higher
number than that, totally independent of the database
connection pool configuration. The idea is that you want
to reuse the connections for someone else during the
"think time" while a user is looking at the last response,
or filling out a new form.
* You can change the underlying persistence storage technology
(say, modify your SQL schemas, or switch to EJBs or JDO,
or combine/split databases) with minimal impact on the
processing logic that uses this database code -- the changes
are encapsulated inside your data access objects.
> -Brian
Craig
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
RE: DBCP exception; very hard to debug
Posted by Brian Menke <br...@innovtech.com>.
Wow! Thanks for the detailed explanation. It makes great sense. I guess
release 2 of the app I'm doing will attempt to use these practices.
Thanks!!
-Brian
-----Original Message-----
From: Craig R. McClanahan [mailto:craigmcc@apache.org]
Sent: Monday, April 28, 2003 9:52 AM
To: Jakarta Commons Users List
Cc: Tomcat Users List
Subject: RE: DBCP exception; very hard to debug
On Mon, 28 Apr 2003, Brian Menke wrote:
> Date: Mon, 28 Apr 2003 09:19:08 -0700
> From: Brian Menke <br...@innovtech.com>
> Reply-To: Jakarta Commons Users List <co...@jakarta.apache.org>
> To: Tomcat Users List <to...@jakarta.apache.org>,
> Jakarta Commons Users List <co...@jakarta.apache.org>
> 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!
>
Sure.
Many beginning web application developers -- especially if you came from
an ASP or PHP background -- start out by lumping the logic to create the
user interface of their page, and the logic to process form submits and
update the database, into the same source file. This works ok for small
scale apps (if I were writing a guestbook type app, i'd certainly do it
this way), but doesn't scale well to large complex apps.
In those environments, you really want to have a "separation of concerns"
between the presentation tier (how does the UI get created) and the
business tier (how does the database get updated), so that you can
maintain and enhance them independently. Further, proper architecture
lets you reuse the same business logic in non-webapp programs that perform
the same tasks (say that you've got logic to update a customer, and you
need it in both an interactive webapp, and a batch processing program, and
a web service).
In the Java world, a number of application frameworks have become popular
to help app developers deal with this sort of thing, by applying
principles from the Model View Controller (MVC) design pattern first made
popular in writing interactive GUI apps. The most popular Java based
framework is Struts (disclaimer -- I'm the original author :-):
http://jakarta.apache.org/struts/
But no matter what you use for architecting the business logic of your
webapp, I would also encourage you to do some research on design patterns
for dealing with the database. I will shoot anyone who tries to take my
copy of "Core J2EE Patterns" by Alur, Crupi, and Malks -- there's lots of
good advice there even if you are not using EJBs -- but there are other
sources as well. Struts, for example, is fundamentally an implementation
of the "Front Controller" pattern described in this book (with lots of
other goodies).
A typical web application architected on good design patterns would
exhibit the following characteristics with respect to the database:
* You'd typically only use one connection per request
(allocating it at the beginning, making it available
as needed, then returning it to the pool) or one
connection per business function (if you hide the
use of the pool inside the persistence tier classes),
unlike your scenario of having 5.
* You'd never store allocated connections in a user's
session -- indeed, highly scalable applications do not
use sessions at all, or only store the minimal amount
of state information required, in order to minimize
memory space usage.
* The net effect of the above is that, if your database
can support X simultaneous transactions, you can support
X simultaneous HTTP requests -- but the number of active
users who have an ongoing session can be a much higher
number than that, totally independent of the database
connection pool configuration. The idea is that you want
to reuse the connections for someone else during the
"think time" while a user is looking at the last response,
or filling out a new form.
* You can change the underlying persistence storage technology
(say, modify your SQL schemas, or switch to EJBs or JDO,
or combine/split databases) with minimal impact on the
processing logic that uses this database code -- the changes
are encapsulated inside your data access objects.
> -Brian
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: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
RE: DBCP exception; very hard to debug
Posted by "Craig R. McClanahan" <cr...@apache.org>.
On Mon, 28 Apr 2003, Brian Menke wrote:
> Date: Mon, 28 Apr 2003 09:19:08 -0700
> From: Brian Menke <br...@innovtech.com>
> Reply-To: Jakarta Commons Users List <co...@jakarta.apache.org>
> To: Tomcat Users List <to...@jakarta.apache.org>,
> Jakarta Commons Users List <co...@jakarta.apache.org>
> 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!
>
Sure.
Many beginning web application developers -- especially if you came from
an ASP or PHP background -- start out by lumping the logic to create the
user interface of their page, and the logic to process form submits and
update the database, into the same source file. This works ok for small
scale apps (if I were writing a guestbook type app, i'd certainly do it
this way), but doesn't scale well to large complex apps.
In those environments, you really want to have a "separation of concerns"
between the presentation tier (how does the UI get created) and the
business tier (how does the database get updated), so that you can
maintain and enhance them independently. Further, proper architecture
lets you reuse the same business logic in non-webapp programs that perform
the same tasks (say that you've got logic to update a customer, and you
need it in both an interactive webapp, and a batch processing program, and
a web service).
In the Java world, a number of application frameworks have become popular
to help app developers deal with this sort of thing, by applying
principles from the Model View Controller (MVC) design pattern first made
popular in writing interactive GUI apps. The most popular Java based
framework is Struts (disclaimer -- I'm the original author :-):
http://jakarta.apache.org/struts/
But no matter what you use for architecting the business logic of your
webapp, I would also encourage you to do some research on design patterns
for dealing with the database. I will shoot anyone who tries to take my
copy of "Core J2EE Patterns" by Alur, Crupi, and Malks -- there's lots of
good advice there even if you are not using EJBs -- but there are other
sources as well. Struts, for example, is fundamentally an implementation
of the "Front Controller" pattern described in this book (with lots of
other goodies).
A typical web application architected on good design patterns would
exhibit the following characteristics with respect to the database:
* You'd typically only use one connection per request
(allocating it at the beginning, making it available
as needed, then returning it to the pool) or one
connection per business function (if you hide the
use of the pool inside the persistence tier classes),
unlike your scenario of having 5.
* You'd never store allocated connections in a user's
session -- indeed, highly scalable applications do not
use sessions at all, or only store the minimal amount
of state information required, in order to minimize
memory space usage.
* The net effect of the above is that, if your database
can support X simultaneous transactions, you can support
X simultaneous HTTP requests -- but the number of active
users who have an ongoing session can be a much higher
number than that, totally independent of the database
connection pool configuration. The idea is that you want
to reuse the connections for someone else during the
"think time" while a user is looking at the last response,
or filling out a new form.
* You can change the underlying persistence storage technology
(say, modify your SQL schemas, or switch to EJBs or JDO,
or combine/split databases) with minimal impact on the
processing logic that uses this database code -- the changes
are encapsulated inside your data access objects.
> -Brian
Craig
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
Re: DBCP exception; very hard to debug
Posted by Erik Price <ep...@ptc.com>.
Brian Menke wrote:
> 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?
http://www.mail-archive.com/tomcat-user@jakarta.apache.org/msg80979.html
Erik
RE: DBCP exception; very hard to debug
Posted by "Craig R. McClanahan" <cr...@apache.org>.
On Mon, 28 Apr 2003, Brian Menke wrote:
> Date: Mon, 28 Apr 2003 09:19:08 -0700
> From: Brian Menke <br...@innovtech.com>
> Reply-To: Jakarta Commons Users List <co...@jakarta.apache.org>
> To: Tomcat Users List <to...@jakarta.apache.org>,
> Jakarta Commons Users List <co...@jakarta.apache.org>
> 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!
>
Sure.
Many beginning web application developers -- especially if you came from
an ASP or PHP background -- start out by lumping the logic to create the
user interface of their page, and the logic to process form submits and
update the database, into the same source file. This works ok for small
scale apps (if I were writing a guestbook type app, i'd certainly do it
this way), but doesn't scale well to large complex apps.
In those environments, you really want to have a "separation of concerns"
between the presentation tier (how does the UI get created) and the
business tier (how does the database get updated), so that you can
maintain and enhance them independently. Further, proper architecture
lets you reuse the same business logic in non-webapp programs that perform
the same tasks (say that you've got logic to update a customer, and you
need it in both an interactive webapp, and a batch processing program, and
a web service).
In the Java world, a number of application frameworks have become popular
to help app developers deal with this sort of thing, by applying
principles from the Model View Controller (MVC) design pattern first made
popular in writing interactive GUI apps. The most popular Java based
framework is Struts (disclaimer -- I'm the original author :-):
http://jakarta.apache.org/struts/
But no matter what you use for architecting the business logic of your
webapp, I would also encourage you to do some research on design patterns
for dealing with the database. I will shoot anyone who tries to take my
copy of "Core J2EE Patterns" by Alur, Crupi, and Malks -- there's lots of
good advice there even if you are not using EJBs -- but there are other
sources as well. Struts, for example, is fundamentally an implementation
of the "Front Controller" pattern described in this book (with lots of
other goodies).
A typical web application architected on good design patterns would
exhibit the following characteristics with respect to the database:
* You'd typically only use one connection per request
(allocating it at the beginning, making it available
as needed, then returning it to the pool) or one
connection per business function (if you hide the
use of the pool inside the persistence tier classes),
unlike your scenario of having 5.
* You'd never store allocated connections in a user's
session -- indeed, highly scalable applications do not
use sessions at all, or only store the minimal amount
of state information required, in order to minimize
memory space usage.
* The net effect of the above is that, if your database
can support X simultaneous transactions, you can support
X simultaneous HTTP requests -- but the number of active
users who have an ongoing session can be a much higher
number than that, totally independent of the database
connection pool configuration. The idea is that you want
to reuse the connections for someone else during the
"think time" while a user is looking at the last response,
or filling out a new form.
* You can change the underlying persistence storage technology
(say, modify your SQL schemas, or switch to EJBs or JDO,
or combine/split databases) with minimal impact on the
processing logic that uses this database code -- the changes
are encapsulated inside your data access objects.
> -Brian
Craig
Re: DBCP exception; very hard to debug
Posted by Erik Price <ep...@ptc.com>.
Brian Menke wrote:
> 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?
http://www.mail-archive.com/tomcat-user@jakarta.apache.org/msg80979.html
Erik
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
RE: DBCP exception; very hard to debug
Posted by Brian Menke <br...@innovtech.com>.
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 <ch...@mac.com>
> Reply-To: Jakarta Commons Users List <co...@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: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
RE: DBCP exception; very hard to debug
Posted by Brian Menke <br...@innovtech.com>.
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 <ch...@mac.com>
> Reply-To: Jakarta Commons Users List <co...@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
Re: DBCP exception; very hard to debug
Posted by Charles So <ch...@mac.com>.
Hello,
I think I have finally figured out what's wrong with the set up.
The 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.
is most likely to occur after I have made changes to the code (either
JSP file or servlet). Please see message included below.
Currently I restarted TC (still using the same configuration and the
same source code), DIDN'T RE-COMPILE THE SERVLETS NOR MAKE CHANGES TO
JSP FILES and repeated the actions >5 times trying to trigger the
exception. No luck thus far! :-)
Although it is still at early stage... I'm still repeating the steps.
I am putting my fingers crossed.
Thanks to everyone who helped me, especially Craig! Hope someone might
benefit from this.
On Tuesday, April 29, 2003, at 12:05 AM, Craig R. McClanahan wrote:
>
>
> On Mon, 28 Apr 2003, Charles So wrote:
>
>> Date: Mon, 28 Apr 2003 13:35:07 +0800
>> From: Charles So <ch...@mac.com>
>> Reply-To: Jakarta Commons Users List <co...@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: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
Re: DBCP exception; very hard to debug
Posted by "Craig R. McClanahan" <cr...@apache.org>.
On Mon, 28 Apr 2003, Charles So wrote:
> Date: Mon, 28 Apr 2003 13:35:07 +0800
> From: Charles So <ch...@mac.com>
> Reply-To: Jakarta Commons Users List <co...@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
Re: DBCP exception; very hard to debug
Posted by "Craig R. McClanahan" <cr...@apache.org>.
On Mon, 28 Apr 2003, Charles So wrote:
> Date: Mon, 28 Apr 2003 13:35:07 +0800
> From: Charles So <ch...@mac.com>
> Reply-To: Jakarta Commons Users List <co...@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