All this makes sense, and I had actually considered the dummy servlet idea. But I have
no
idea how to get the connection from the servlet.
Let's say my servlet class is called connPool. I have a index.jsp page that calls
getName(ssn) passing social security number. The getName is a method from class dbBean
(database bean). The database bean without any connection pooling looks like this:
public String getName( string userSSN )
{
try
{
db.connect();
ResultSet rs1 = db.query( "select name from user_info where ssn = '" + userSSN + "'; "
);
if( rs1.next() )
{
return rs1.getString( "name" );
}
db.close();
}
catch( Exception e )
{
db.close();
}
}
Now how do I call the connPool servlet to get a connection to use in place of
db.connect()?
Brian N. Burridge
Lead Internet Analyst
Cox Target Media
Craig R. McClanahan wrote:
> 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".
