The best approach, IMHO, is not use database connection pooling yourself at
all. Use J2EE, and the application server normally handles pooling for you
via a JNDI reference, so using a pool becomes trivial... and you're not
coding it.
Even better is to avoid accessing the database directly in JSP at all, via
EJBs - session beans if you absolutely HAVE to do something with SQL
directly, but entity beans if you're manipulating data.
Why do you want to avoid SQL?
Complex answer, rooted deep in the heart of J2EE. Basically, there are at
least two roles in J2EE development: developer and deployer. (I'm
simplifying.) The developer writes code; the deployer deploys it. (Big
surprise, huh?) The enabling concept here is that the developer writes code
that can be deployed anywhere, and the deployer is responsible for little
annoying details that apply specifically to his deployment.
For a little walk-through that hopefully shows the roles and how they work,
suppose Developer A writes a... phone book EJB set (a group of beans
designed to work on a phone book, including people, addresses, and users;
includes entity beans and session beans.) A, being a good developer, doesn't
code any SQL, and sends the code off.
Deployer, Mr. B, gets the code, and he's decided that he's going to try
using an OODBMS. (Overkill, to be sure!) All he has to do is write
a file for his application server, that maps the entity beans to his OODBMS,
and uses the OODBMS' methods to locate specific instances. (See note 1.) He
later realises that OODBMS is a bit heavy for such a light application,
rewrites his one EJB deployment file, and off he goes.
Note that this is quite feasible in the wild. A bit contrived in this case,
to be sure - you'd want to know what you were deploying to ahead of time,
changing is midstream is a scary prospect. However, this is quite doable
(and I've done it in the past, serving as deployer and developer.) Note that
at no point did the deployer have to change any code to handle pooling
references, and a "list of tables" is unnecessary, and for that matter,
"tables" are unnecessary in the final analysis. (They ended up being used,
but that's a deployment decision, not a development decision.) Field names,
table names, the entire deployment phase was handled *by the deployer*, not
the developer.
To me, that's the way to go.
Note 1:
EJB 2.0 (still in Draft, as far as I know) specifies a standard query
language for EJB finder methods, so you no longer have to rely quite so much
on DB or application server specifics.
>Hello,
>
>I'm new to JSP and JDBC, now I wonder how I can best realize the
>"Connection
>Pooling" mentioned everywhere. In the book >>Special Edition Using Java
>Server
>Pages and Servlets<< the author introduced some mechanisms to deal with
>Connection Pooling. The basic idea is simply holding some connections with
>a
>conneciton manager, when a process needs connection, it demands it from the
>connection manager; when it is done using a connection, instead of closing
>it,
>it simply release the connection to the connection manager so that it can
>be
>allocated to other processes.
>I'm not sure if I'll be good off with this simplistic approach, is there
>anything that I should take into consideration? And is there any Java
>packages
>available for this purpose?
>Many thanks in advance!
>
>regards
>ZHU Jia
>
>===========================================================================
>To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff
>JSP-INTEREST".
>For digest: mailto [EMAIL PROTECTED] with body: "set JSP-INTEREST
>DIGEST".
>Some relevant FAQs on JSP/Servlets can be found at:
>
> http://java.sun.com/products/jsp/faq.html
> http://www.esperanto.org.nz/jsp/jspfaq.html
> http://www.jguru.com/jguru/faq/faqpage.jsp?name=JSP
> http://www.jguru.com/jguru/faq/faqpage.jsp?name=Servlets
_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com
===========================================================================
To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff JSP-INTEREST".
For digest: mailto [EMAIL PROTECTED] with body: "set JSP-INTEREST DIGEST".
Some relevant FAQs on JSP/Servlets can be found at:
http://java.sun.com/products/jsp/faq.html
http://www.esperanto.org.nz/jsp/jspfaq.html
http://www.jguru.com/jguru/faq/faqpage.jsp?name=JSP
http://www.jguru.com/jguru/faq/faqpage.jsp?name=Servlets
