Mailing-List: contact tomcat-user-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Tomcat Users List" <tomcat-user@jakarta.apache.org>
Mime-Version: 1.0 (Apple Message framework v606)
In-Reply-To: <3FCD97D6.40204@ev.co.yu>
References: <67A8A2CC-253F-11D8-BEC7-0030656EC0E4@mac.com>
 <200312032022.56558.peter.harrison@nothingbutnet.co.nz>
 <3FCD97D6.40204@ev.co.yu>
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <25973DCA-257D-11D8-A01C-0030656EC0E4@mac.com>
Content-Transfer-Encoding: 7bit
From: "Todd O'Bryan" <toddobryan@mac.com>
Subject: Re: Servlets with JDBC connectivity
Date: Wed, 3 Dec 2003 05:40:43 -0500
To: Tomcat Users List <tomcat-user@jakarta.apache.org>


On Dec 3, 2003, at 2:59 AM, Nikola Milutinovic wrote:

> Peter Harrison wrote:
>> On Wed, 03 Dec 2003 16:18, Todd O'Bryan wrote:
>>> How do people handle this elegantly? The requirements are: a single,
>>> globally visible (within a webapp) database interface and the ability
>>> to access multiple databases easily.
>> The first point is to use a singleton to set up the database 
>> connection - or more correctly the connection pool. This way you can 
>> request a connection and return it to the pool easily. Of course 
>> every time you use one you will have to use try-catch blocks. Sorry 
>> no way around that.
>
> Both Tomcat and J2EE specification support javax.sql.DataSource 
> objects over JNDI. That is how we handle it elegantly.
>
> A DataSource object is specified by the administrator and created by 
> the container. Container then deploys it under specified JNDI name. A 
> servlet (or EJB) can then lookup this object and use it, something 
> like this:
>
> import java.sql.*;
> import javax.sql.*;
> import javax.naming.*;
>
> InitialContext ic = new InitialContext();
> DataSource ds = (DataSource)ic.lookup( 
> "java:comp/env/jdbc/MyDataSource" );
> Connection conn = ds.getConnection();
>

But this means I still have to get a connection, create a statement, 
and execute a query or update on the statement in every servlet where I 
want to use the connection. Yes, it locates the connection details 
(i.e., the JDBC connection method, the database name, user and 
password) somewhere centrally so that I don't have to keep coding it, 
but all of the connection overhead still has to be dealt with in every 
servlet in a webapp.

At least, I think that's what it's doing. Am I missing something?

Here's what I want. In every servlet in my webapp, I'm only going to be 
using one of a very few database connections. I'd like to be able to do 
something like:

Test.executeQuery("SQL")

without doing any setup because the Test class handles all the setup, 
initializes the connection the first time it's called, etc.

Basically, it's a singleton class that never gets an instance created 
because if I create an instance, I'd have to pass it around to all the 
servlets in the webapp, which would kill the convenience of having it 
be available with minimal overhead.

Oo, oo, oo...

As I've been sitting here writing this, I had a brainstorm. What if I 
create an abstract class that has all the database connectivity built 
into it as static methods, but is just waiting for a connection method, 
a username, and a password. Then creating a new JDBC connection which 
is visible to all my servlets is just a matter of making a concrete 
subclass that defines those three variables and inherits all the 
functionality from its abstract parent class.

Any reason this is a horrible idea?

Thanks for being patient,
Todd


---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org