Craig,
If your ConnectionPool (or other shared collection) lives in the servlet context, how
would your
non-serlvet objects use the ConnectionPool? I assume you would have the servlet pass
the
ConnectionPool as an argument to the non-servlet object.
In my scheme, there is a layer between the servlets and the database, which I call the
dbobject
package. This package implements generalized methods for handling insert, query, etc
for various
datatypes. For each Oracle table, I inherit a new class, writing only a constructor,
gets and sets.
My DbObject class handles the rest.
The servlet uses the dbobject, never touches jdbc, and can not even see the protected
ConnectionPool.
Do you see any potential drawbacks to my approach?
Thank you for your valuable insights,
Adam
Craig McClanahan wrote:
> Adam Vernon wrote:
>
> > Hi Craig,
> >
> > I included some of your discussion below. You talk about keeping the
>ConnectionPool in the
> > ServletContext. Why not use a static class interface for the ConnectionPool?
>Would it not be
> > available to the JSP pages?
> >
> > Adam
> >
>
> Yes, static variables would be available -- in a JSP page, you could use a scriptlet
>to access
> these values. I tend to avoid static variables for several philosophical reasons,
>however:
>
> * Static variables tend to make me lazy about good
> object-oriented design (especially on encapsulization
> and information hiding issues). I find that my applications
> are better architected if I resist the temptation to
> use statics.
>
> * Static variables are available *everywhere* in your
> application, not just where you need them to be. This
> can make debugging much harder when mysterious
> changes to these variables occur. It's like going back
> to COMMON variables in the old Fortran days (if that
> means something to you, you're probably old like I am :-).
>
> * In particular for JSP pages, you don't get to use the
> <jsp:useBean /> mechanism to declare the associated
> variable. Since you have to use a scriptlet to declare
> it, you're going to find yourself tempted to put business
> logic in the JSP pages as well -- which I also try to
> avoid in my app designs.
>
> * Static variables are singletons. This is OK if you are
> running your app in a dedicated JVM, but what if that is
> not the case? What if there is another servlet based app
> in the same servlet container, that wants to use the same
> static variable to store it's connection pool? In a servlet
> and JSP based world, you cannot assume that you will
> always have 100% occupancy of the server you run in.
>
> NOTE: The last point becomes more complicated in servlet containers that implement
>custom class
> loaders -- it may or may not be true, depending on whether the class containing
>your static is on
> the system class path or not. But the basic issue still remains.
>
> Craig
===========================================================================
To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff JSP-INTEREST".
FAQs on JSP can be found at:
http://java.sun.com/products/jsp/faq.html
http://www.esperanto.org.nz/jsp/jspfaq.html
