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 19:52:13 GMT


On Tue, 12 Nov 2002, Roytman, Alex wrote:

> Date: Tue, 12 Nov 2002 13:16:07 -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,
>
> Thank you very much again.

> 1. As you said there are aspects to JNDI in tomcat. I am primarily
> interested in in memory JNDI which is used to implement j2ee environment
> plus config file (server.xml like) digester to configure declare and
> configure resources, environment entries etc. retaining complete tomcat
> syntax. There was a JSR for client side J2EE like environment but I
> though it was dropped.

(It's true that the JSR you refer to got dropped, but every J2EE server
has to be able to support "application clients".)

If the org.apache.naming stuff were to be moved to commons, I think you'd
get resistance to copying the server.xml reading stuff as well, except
perhaps as an example application.  The Commons packages tend to be as
small and self-contained as they can be, and a common theme has been that
the configuration of a package's classes should generally be separate from
the package itself.  That being said, some code that read an XML config
file of some sort, and used it to populate one or more JNDI contexts,
would be a dandy example of naming and digester.


> 2. Exposing ServletContext via JNDI is tomcat specific but all I want it
> for is to help other tomcat specific JNDI factories to do their job.

> 3. Yes I fully understand javax.sql.DataSource wrapper around pool
> concept and I actually use it for my factories. The only question I have
> is whether tomcat creates a separate instance of JNDI factory (the one
> implementing javax.naming.spi.ObjectFactory) per resource (pool) or
> shares the same instance of JNDI factory for all similar resource
> (please note it has nothing to do with whether it is a shared global
> resource or context specific one). Depending on the answer (and I will
> try to go through JNDI specs once again) the mechanism of wrapping might
> be different.

There's a separate instance of the appropriate object factory for each
resource -- per the JNDI spec requirements.

>
> Thank you very much again for your help.
> It always amazes me how you manage to do so much and also help people on the mailing
lists :-)
>
> Alex
>

Craig


>
> > -----Original Message-----
> > From: Craig R. McClanahan [mailto:craigmcc@apache.org]
> > Sent: Tuesday, November 12, 2002 12:51 PM
> > To: Jakarta Commons Developers List
> > Subject: RE: DBCP: Jdbc2PoolDataSource needs attention
> >
> >
> >
> > 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>
> >
> >
>
> --
> 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