commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Craig R. McClanahan" <>
Subject RE: DBCP exception; very hard to debug
Date Mon, 28 Apr 2003 16:51:36 GMT

On Mon, 28 Apr 2003, Brian Menke wrote:

> Date: Mon, 28 Apr 2003 09:19:08 -0700
> From: Brian Menke <>
> Reply-To: Jakarta Commons Users List <>
> 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!


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 :-):

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


View raw message