Brian Burridge wrote:
> 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.
>
As you might have guessed, I did not just pull that example out of the air :-). I
use application scope to store a connection pool object in exactly the manner I
described.
I haven't used DBConnectionBroker myself, but I would guess that nothing *restricts*
you from using it in the manner I described. The only interesting part is getting
the thing created and stored in the servlet context in the first place. My current
approach to this is to have a dummy servlet that initializes the connection pool and
calls setAttribute(), and I tell my servlet engine to load the dummy servlet at
servlet engine startup time. The servlet is never actually called by a user -- it's
only purpose is to create the connection pool.
>
> 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.
>
This is a really interesting object-oriented design issue, and applies to any sort of
environment (not just servlets and JSPs) where you want to an object to represent
some information that is stored in a database. How do you ever link the object to
the JDBC connection to use for reading and writing?
The approach I'm currently taking (not totally satisfying, but it works) goes like
this:
* The connection pool is created and stashed in
the servlet context as described above.
* When a database bean is created, I pass to it's
constructor a reference to the connection pool
(these act like pointers in C/C++, they don't
make copies of the pool object).
* Now, when the database bean needs to read
from the database to respond to a call to
getUserName(), it allocates itself a connection
from the pool, reads the appropriate value, and
then releases the connection. <<<Side note:
be sure you always release any connection that
you allocate before returning the result page to
the user -- otherwise you are tying up server
resources that are better utilzed serving other
requests while the user is reading the HTML
from this one>>>
* Users of this "database bean" have no clue that it really
uses a database behind the scenes. In particular,
the method signatures for properties still conform
to the standard JavaBeans naming patterns, which
is important for JSP to access the properties easily.
In my designs, I tend to use the "Model 2" application design that was described in
the JSP 0.92 spec -- basically, I do all the business logic and bean creation in a
servlet, store the results in beans in the appropriate scope (usually either request
or session), and then forward control to a JSP page to format the resulting HTML.
You can do the same sorts of stuff with only JSP pages, but you're going to need to
embed some Java code in scriptlet tags (<% %>), which gets copied into the servlet
that is actually generated for your page by the JSP compiler.
>
> 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.
>
Don't feel bad -- whenever I ever start thinking I've got it all down, some new
circumstance comes up and whacks me in the nose anyway :-)
>
> Brian N. Burridge
> Lead Internet Analyst
> Cox Target Media
>
Craig McClanahan
===========================================================================
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".
