Interesting that you brought of conneciton pools because that is exactly what I'm
trying to do. We are using JSP for everything here, and I have a database bean
with all my SQL in it. I decided a connection pool was necessary, and downloaded
DBConnectionBroker from javaexchange.com (it's free.) The problem is that it is
designed for servlets. The conneciton pool is local to each servlet, and is
started in the init class, and destroyed in the destroy class. In order for me to
use this, I have to have it in a scope outside a session or page. So I am working
on the application scope. I am hoping that I can start a connectionPool bean in
each JSP page with an application lifespan, and have a pool of connections for
each app. It is a little mind boggling, plus I'm new to Java, and I'm not even
sure if when I get this done, the theory is even going to work. Plus, with this
strategy I will have to open the database connection in the jsp page and then pass
it to my database bean, which is the opposite of my goal.
My goal was to have all database activity (opens, closes, selects, etc) in the
database bean, and the JSP page simply calls methods like getUserName, etc. But
how does my database bean call a global connection pool to get a connection when
I'm using the 2 tier approach? Which I've read is better than the 3 tier approach,
which is looking better and better every minute.
I think I've confused myself on this so much now that I couldn't see the answer if
it was on the end of my nose.
Brian N. Burridge
Lead Internet Analyst
Cox Target Media
Craig R. McClanahan wrote:
> Brian Burridge wrote:
>
> > What would destroy the application object?
> >
> > Brian N. Burridge
> > Lead Internet Analyst
> > Cox Target Media
> >
>
> That's a pretty interesting question, actually.
>
> The 2.1 servlet specification does not say much, other than that a servlet
> context "defines the servlet's view of the servlet engine." In the reference
> implementation, and in other servlet engines I am familiar with, the lifetime
> of the servlet context is from when the servlet engine is started until when
> it stops. You can, of course, remove an application-scoped object at any time
> yourself, by using the ServletContext.removeAttribute() method.
>
> The 1.0 JSP spec says that "All references to the object [stored with
> application scope] shall be released when the runtime environment reclaims the
> ServletContext. Presumably, this only happens when the servlet engine shuts
> down.
>
> Note that there is no mechanism for your object to know when it is added to,
> or removed from, the servlet context. This is a hole in the current servlet
> API, and I would expect to see something similar to HttpSessionBindingListener
> added for objects that are being bound and unbound from the servlet context
> (i.e. application scope) and from the request (i.e. request scope) in some
> future version of the servlet API.
>
> Example: let's say you used this approach to share a JDBC connection pool
> object for your beans and servlets. There is no way for the servlet engine to
> tell the connection pool to shut down gracefully, so you'll need to manage
> that by some application specific means in the mean time.
>
> Craig McClanahan
>
> Gabriel Wong wrote:
>
> >
> > > Brian Burridge wrote:
> > > >
> > > > Has anyone used the "application" lifespan? Am I correct in assuming
> > > > that this functions similiar to a servlet, in that if I use
> > > > "applicaiton" lifespan, the bean and its contents (objects) are
> > > > accessible to that application, even across user sessions, until the
> > > > server unloads the servlet, probably through shutdown/restart?
> > > >
> > > > I haven't used this lifespan before, but need to use a global object
> > > > across sessions. I am using spec .92.
> > > Yes to the above but note unloading a servlet does not mean the
> > > application object is destroyed.
> > >
> > > Gabriel Wong
> > > http://www.ezwebtools.com
> > > -------------------------
> >
> > ===========================================================================
> > To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
> > of the message "signoff JSP-INTEREST". For general help, send email to
> > [EMAIL PROTECTED] and include in the body of the message "help".
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff JSP-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
