commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Anton Tagunov <>
Subject Re[4]: [dbcp] Do we need Referenceable?
Date Thu, 10 Jul 2003 05:59:39 GMT
Hello John,

AT> With Tomcat we're in a different position.

JM> What happens if tomcat changes its process to use the standard jndi
JM> pattern described above?  What about a developer wishing to use dbcp
JM> with another servlet container or app server?  Why are you advocating
JM> that dbcp tie itself exclusively to implementation details of tomcat? 
JM> (btw, i do use tomcat almost exclusively myself).
AT> But what use for our product to implement Referenceable then?
AT> It will never have Context.bind() called on it.

JM> How can you presume that?

Well, I'm changing my argumentation now, but not the outcome :)

While the Referenceable and Serializable capabilities are generally
useful for JNDI boun objects I think that with Pool objects this
is not the case.

In fact the Pool should be a sort of a singletone.
Strictly one instance per the Context it has been bound to.
(Yes I know there may be multiple JNDI paths leading to the
same location, but lets assume that there is only one "home"
context it is being bound to. And there should be strictly
one pool per each binding to a "home" context.)

Then the only meaningful reference that can exist to this
object is the object itself.

Or, we can have some static HashMap that maps id -> instance,
and then the id will be a good reference too, but essentially
this is not different from a real object reference is it?

The pool reference won't make sense out of JVM (or even maybe
a classloader it came from).

So I state: though in general it is advisable for JNDI
bound objects to be Serializable/Referenceable with Pools
this is not the case. A pool should be bound into JNDI
directly, not a reference to it. Same with any
"quasi-singletone" object (in the sense defined above).

If someone will search for a way to use DBCP out of
Tomcat with JNDI his best bet will be to
a) initialize an instance of the Pool (not the factory even)
   with appropriate settings
b) bind it to JNDI directly

Any references would be meaningless.

BTW I feel that Tomcat way of doing things with JNDI is also
bad for us. It would be highly preferable to bind the Pool
not the factory to the Cotext. (Since if more then one
pool is configured in Tomcat, it may well happen that only
a single factory will be instantiated, so I'm probably going
to talk that over on Tomcat user or dev list, when I have time,
ha-ha! :)

- Anton

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message