commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Roytman, Alex" <Roytm...@peacetech.com>
Subject RE: DBCP: Jdbc2PoolDataSource needs attention
Date Tue, 12 Nov 2002 01:48:08 GMT
Craig, 

Sorry, I did not make myself clear. When I said "make it tomcat context aware" I meant web
context not JNDI context. 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). 
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.

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.

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

Thanks again for your help

Alex
 

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


Mime
View raw message