commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Craig R. McClanahan" <craig...@apache.org>
Subject Re: [DBCP] JNDI, Tomcat, Distributed Apps, et al.
Date Sat, 15 Jun 2002 21:48:07 GMT


On Sat, 15 Jun 2002, Les Hazlewood wrote:

> Date: Sat, 15 Jun 2002 22:09:46 +0100
> From: Les Hazlewood <les@hazlewood.com>
> Reply-To: Jakarta Commons Developers List <commons-dev@jakarta.apache.org>
> To: commons-dev@jakarta.apache.org
> Subject: [DBCP] JNDI, Tomcat, Distributed Apps, et al.
>
> Hey folks,
>
> I've been well-immersed in the dbcp code and the jndi tutorial the last
> week, and I have some questions concerning the dbcp commons project.
>
> I have just recently implemented DBCP in my webapp using Tomcat per the
> instructions on the JNDI Resources How-To:
> http://jakarta.apache.org/tomcat/tomcat-4.1-doc/jndi-resources-howto.html
>
> Its great!  Thanks for the tool.
>
> I'd like to address 3 areas of confusion:
>
>
> Situation 1:
>
> I'd like to use the DBCP in a JNDI lookup from outside a webapp container
> like Tomcat.  I.E. I'd like to do it in a standalone application as well
> that accesses the same database.
>
> After all the reading I've done, I'm still wondering if there is a way to do
> a JNDI lookup to return a BasicDataSource in my standalone app, just like
> Tomcat does for my webapp.
>

In order for this to work, you need to use a JNDI provider that lets you
register the object factory.  There are a bunch of standard providers
available (like one that uses LDAP to talk to a directory server) --
conceptually, you should be able to bind an object factory into one of
these, but I've never tried it.  The other approach would be to write your
own implementation of javax.naming.Context and set the appropriate system
properties to use your version -- details in the JNDI spec and tutorials.

Note that if you are building a J2EE stand-alone application, the platform
will provide a JNDI naming context for you, just like Tomcat does.  JNDI
specs (and you'll want to look at the Service Provider Interface spec too)
are available via:

  http://java.sun.com/products/jndi


> Can I specify the DB parameters in a jndi.properties file that my standalone
> app accesses, just like Tomcat's server.xml specifies Resources and
> ResourceParams? (i.e. maxActive, maxIdle, url, etc in a jndi.properties
> file).
>

Details would depend on which JNDI provider you use, and how it's
configured.  But you'll definitely need to do some sort of external
configuration.

> If we CAN specify such properties and access them throughout the webapp,
> what is the point of specifying them in Tomcat's server.xml file?  I ask
> because if we need JNDI lookup of a DataSource in Tomcat you have to
> manually configure the server.xml file to use it.  This goes against the
> principle of packaging things in a nice self-contained .war file and having
> the application work just by dropping it in to the webapp directory (that
> is, there should be no external configuration necessary outside of the war
> context).
>

J2EE describes the overall application development and installation
process in terms of roles, and (in particular) defines a "deployer" role
where the responsibility is to resolve all of the "resource references" in
a deployment descriptor to match up to the actual resources to be used.
Typically, the app server will provide tools to help you do this as part
of deploying your app.  Tomcat has some tools for this as well in 4.1.x,
and the version of Tomcat shipped in the Java Web Services Developer Pack
that was just released <http://java.sun.com/webservices/> includes a
modified version of "deploytool" from the J2EE reference implementation
that makes this very easy.

Here's an example use case why external configuration is very useful.
Consider an environment where you have different servers for development,
testing, and production.  Obviously, the database connection parameters
for the databases associated with each server are going to be different.
Because the JNDI resources are defined in the server configuration, you
can use exactly the same WAR file -- unmodified -- in each of the three
envioronments.

>
> Situation 2:
>
> I've noticed that the BasicDataSourceFactory creates a new instance of a
> Datasource, which intuitively means it has its own pool of connections
> withing the memory space of the JVM that created it.  For distributed
> applications that exist on multiple JVM's but access the same database, this
> would mean a DataSource object with a corresponding connection pool exists
> per JVM.
>

Yep.

> When I specify things such as maxIdle, maxConnections, etc., I'd like that
> to correspond to global settings for my database.  For example, lets say I
> know database x can handle 50 open connections concurrently, so no matter
> how many distributed applications that access my database, I don't want more
> than 50 connections total to be pooled across all pooled applications.
>
> The only way I can think of doing this is to create a single instance of a
> DataSource via a JNDI lookup, and then bind this DataSource object in a JNDI
> Context.  Then all other applications can do a JNDI lookup on this bound
> object, and just use it as if they created the DataSource themselves.
>
> However, I'm not entirely sure this is possible, if it requires things like
> Serialization, or behind-the-scenes RMI, of which I'm not clear since I'm
> not a JNDI expert by any means.  Any ideas?
>

It's not ... and this isn't related to the fact that you are grabbing your
data source via JNDI.  It's fundamental to the nature of what the
connection pool actually does -- it pools a set of java.sql.Connection
objects.  In the usual case, there will be some sort of TCP socket nested
inside that connection for use in communicating to the real database -- so
you can't share Connection instances across different JVMs anyway.

You will either have to manage the max active connections as you deploy on
each distributed server instance, or write some sort of fancy "distributed
data source" gadget that communicates between the data source instances
behind the scenes somehow.

>
> Situation 3:
>
> I've noticed DBCP doesn't use things like the newer JDBC standardized
> interfaces such as ConnectionPoolDataSource and PooledConnection.
>
> These are Java SQL Standards, and I was wondering if there are any plans to
> incorporate these soon or what measures have been done already.  I feel its
> important to adhere to the standards, and Apache has always been great about
> that.
>

John McNally (author of a bunch of the code in the "jdbc2pool" package in
jakarta-commons-sandbox, which deals with some of these things) has
recently proposed merging that code in with DBCP, so I'd guess the answer
is "yes".  I'm not sure what different it makes to an application, though;
the J2EE platform standard is to access a java.sql.DataSource instance
from your JNDI naming context, which DBCP already supports.  (See the J2EE
platform specification for dteails.)

> Your thoughts?
>
>
> Thanks a ton,
>
> Les Hazlewood
>

Craig


--
To unsubscribe, e-mail:   <mailto:commons-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:commons-dev-help@jakarta.apache.org>


Mime
View raw message