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: Jdbc2PoolDataSource needs attention
Date Tue, 12 Nov 2002 17:51:22 GMT

We're drifting to what should probably be a TOMCAT-USER discussion, but
...

On Mon, 11 Nov 2002, Roytman, Alex wrote:

> Date: Mon, 11 Nov 2002 20:48:08 -0500
> From: "Roytman, Alex" <Roytmana@peacetech.com>
> Reply-To: Jakarta Commons Developers List <commons-dev@jakarta.apache.org>
> To: Jakarta Commons Developers List <commons-dev@jakarta.apache.org>
> Subject: RE: DBCP: Jdbc2PoolDataSource needs attention
>
> Craig,
>
> Sorry, I did not make myself clear. When I said "make it tomcat context
> aware" I meant web context not JNDI context.

OK, now I get it.

> I found it is very useful to have access to tomcat web context via JNDI
> - it lets my JNDI factories which are context specific and need to know
> about web context real path or context logging facility etc. to be
> configured properly. I wish tomcat provided it out of the box because it
> seems to be very useful (as I said right now I use a tomcat context
> listener to do it).

It's certainly technically easy to do -- of course, it's not in the specs,
so this is a Tomcat specific feature that you're relying on.

One possible negative consequence of making the ServletContext available
in this way is that it ties any code using the ServletContext to require
being run in a servlet container.  You don't generally want to do that for
generally reusable business logic, but it's probably fine for stuff that
is clearly servlet container dependent already.

>  Now let me try to explain why I thought there may
> be a possibility for the same jndi names declared in different tomcat
> contexts.  If resource factory is not cached by tomcat
> getObjectInstance() will be called on each lookup In case of jdbc
> connection pool we do not want to create new pool instance every time so
> we would have to cache it. If each resource declared in JNDI receives
> its own JNDI factory instance there will be no problem because caching
> will mean JNDI factory will create an instance of pool on first lookup
> and return the same instance on subsequent lookups. However if there is
> no guarantee (and here I am not clear about JNDI specs) that JNDI will
> create new JNDI factory instance for each resource, it might happen that
> the same instance of JNDI factory will be used to create all similar
> resources in one or more web contexts. In this case caching will have to
> be done via static map keyed by particular resource's distinguished name
> - which I believe does not have to be unique across multiple web
> contexts - this is where potential name collision could happen. So to
> avoid it, this map should be keyed by web context + resource's
> distinguished name.
>

There's a couple of different dimensions here, and I'd like to address
them separately.

* Tomcat 4.1 already supports a mechanism of sharing data sources
  (or any other resources) across web applications -- define
  the resources themselves in the <GlobalNamingResources> section
  of server.xml, and use a <ResourceLink> -- think of it as a
  symlink -- inside the <Context> element.

* Even if the JNDI objects are created every time they are
  retrieved, that does *not* mean that a connection pool itself
  must be created every time -- the object factory can simply
  return a wrapper (implements javax.sql.DataSource) around an
  existing pool.  This isn't what Tomcat does today, but would
  be the appropriate way to implement this.

> I am not very strong as far as specs go so I would really appreciate if
> you could give us some clarification and guidelines on this matter. I
> have quite a few custom (non jdbc) resource factories developed for
> tomcat and would like to understand how tomcat JNDI will work in future.
>

>From a spec perspective, the only required (and therefore portable)
support for JNDI resources is to support those that have deployment
descriptor elements (like <resource-ref> and <ejb-ref>), and even then are
only required in a J2EE app server.  The J2EE spec defines the types of
resources that must be supported (for 1.4, the list includes things like
JDBC data sources, EJBs, JMS message queues, a UserTransaction creator,
and so on).

Stand-alone servlet containers are not required to even support JNDI at
all -- although Tomcat 4.x does so (and supports the resources it can in a
manner that is designed to be upwardly compatible with J2EE servers).

Note that Tomcat doesn't define any particular magic for populating the
naming context in the first place -- it relies on the existence of object
factories that implement the standard JNDI service provider API
(javax.naming.spi.ObjectFactory).  See the JNDI Spec, and the Service
Provider Interface Spec, for more details:

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

> PS It would be really great if tomcat JNDI is separated from tomcat to
> become another Jakarta commons subproject. I am sure many people would
> want to integrate JNDI into their product even if those products are not
> "servers" just to have uniformed resource access for their code
> regardless whether it runs within a container (i.e. tomcat) or not. I
> myself have many components which are used inside of tomcat or in
> standalone client apps and I would love to easily add jndi to those
> standalone apps and declare all resources in something like "server.xml"
> and access them via JNDI
>

I think this (naming --> commons) would be a fine idea -- the need, of
course, is for someone to take the time to actually do it.

Volunteers for this will quickly find that there are two layers in the
JNDI stuff in Tomcat -- a generic layer that creates in-memory JNDI
contexts (the part that would make sense in commons) and Tomcat-specific
adaptations (such as the naming context that represents the static
resources of a web applicaiton).  These are slightly intertwined in the
current code, but it wouldn't be that hard to disentangle them.

The Tomcat-specific stuff isn't going to be generally useful (unless you
want to build another servlet container, of course :-).

Side note -- J2EE app servers also define a thing called a "J2EE
application client" that can access all the services of the app server,
including the JNDI naming context.  You might investigate using one of
those to have access to JNDI-based resources in non-servlet programs.

> Thanks again for your help
>
> Alex

Craig


>
>
> -----Original Message-----
> From: Craig R. McClanahan [mailto:craigmcc@apache.org]
> Sent: Monday, November 11, 2002 5:55 PM
> To: Jakarta Commons Developers List
> Subject: RE: DBCP: Jdbc2PoolDataSource needs attention
>
>
>
>
> On Mon, 11 Nov 2002, Roytman, Alex wrote:
>
> > Date: Mon, 11 Nov 2002 15:32:46 -0500
> > From: "Roytman, Alex" <Roytmana@peacetech.com>
> > Reply-To: Jakarta Commons Developers List <commons-dev@jakarta.apache.org>
> > To: Jakarta Commons Developers List <commons-dev@jakarta.apache.org>
> > Subject: RE: DBCP: Jdbc2PoolDataSource needs attention
> >
> > Hi Craig,
> >
> > Thank you for clarification. If that is tha case I think there is one
> > important thing to add to tomcat JNDI - make it tomcat context aware so
> > object factory knows which context it was invoked from. It will allow to
> > avoid JNDI name collisions across contexts and it has some other usages
> > (like factory being able to grab config files from contexts real path
> > etc). Right now I use tomcat listener to publis context as environment
> > entry so it can be looked up via JNDI by other JNDI factories
> >
>
> The factory that is used for connection pools
> (org.apache.commons.dbcp.BasicDataSourceFactory) uses the standard JNDI
> "ObjectFactory" APIs, so it receives an instance of the Context instance
> in which the new name is being created.  As long as Tomcat is actually
> providing the correct instance (i.e. the one for your webapp versus other
> webapps), there should not be any name clash issues.
>
> Thus, it's not clear to me where name clashes are coming from, or what the
> proposed patch would be.  Could you help me out here -- most effectively
> by submitting bug reports (with a test case) against Tomcat and/or
> commons-dbcp that demonstrates the problem you are having?
>
> > Alex
>
> Craig
>
>
> >
> > -----Original Message-----
> > From: Craig R. McClanahan [mailto:craigmcc@apache.org]
> > Sent: Monday, November 11, 2002 12:30 PM
> > To: Jakarta Commons Developers List
> > Subject: Re: DBCP: Jdbc2PoolDataSource needs attention
> >
> >
> >
> >
> > On 10 Nov 2002, John McNally wrote:
> >
> > > >
> > > > 5. Not sure why we need to keep a static map of all pools by datasource.
J2EE environment will call jndi environment getObjectInstance() only once to create a pool
and then the environment will keep the reference and will not call factory method on each
object lookup but return previously created instance
> > > >
> > >
> > > Tomcat may do this, I do not know.  But I do not think a jndi service is
> > > required to return the same instance to every lookup.  Is there a
> > > specification that says J2EE containers will cache instances?  The jdbc
> > > spec mentions use of static fields as a way to code around the fact that
> > > there might be multiple instances which should be referring to the same
> > > pool of connections.
> > >
> >
> > The situation with regard to caching instances (and related concerns about
> > the immutability of the instances being returned) was ambiguous in the
> > J2EE 1.2 and 1.3 specs, but has been clarified in J2EE 1.4 (Proposed Final
> > Draft), section 5.2:
> >
> >     In general, lookups of objects in the JNDI "java:" namespace
> >     are required to return a new instance of the requested object
> >     every time.
> >
> > There are some listed exceptions to this rule (primarily for things that
> > are known to be immutable (such as a java.lang.String) or designed to be
> > singletons (at the JVM level), but these exceptions don't apply to things
> > like JDBC data sources.  Looks like we'll have to change things in Tomcat
> > 5.
> >
> > Section 5.4 talks in more detail about the container's responsibilities
> > related to resource manager connection factories in a J2EE app server
> > environment.
> >
> > You can grab the J2EE 1.4 PFD platform spec at:
> >
> >   http://java.sun.com/j2ee/download.html
> >
> >
> > > john mcnally
> > >
> >
> > Craig
> >
> >
> > --
> > To unsubscribe, e-mail:   <mailto:commons-dev-unsubscribe@jakarta.apache.org>
> > For additional commands, e-mail: <mailto:commons-dev-help@jakarta.apache.org>
> >
> >
> > --
> > To unsubscribe, e-mail:   <mailto:commons-dev-unsubscribe@jakarta.apache.org>
> > For additional commands, e-mail: <mailto:commons-dev-help@jakarta.apache.org>
> >
> >
>
>
> --
> To unsubscribe, e-mail:   <mailto:commons-dev-unsubscribe@jakarta.apache.org>
> For additional commands, e-mail: <mailto:commons-dev-help@jakarta.apache.org>
>
>
> --
> To unsubscribe, e-mail:   <mailto:commons-dev-unsubscribe@jakarta.apache.org>
> For additional commands, e-mail: <mailto:commons-dev-help@jakarta.apache.org>
>
>


--
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