Hello, All develpers interested in DBCP!
I was reviewing code of Jdbc2PoolDataSource when I hit this question.
I even have done a good deal of reading on JNDI yesterday to educate
myself on the subject, although I did not master it _all_ though.
Now I have a question: do we really need
DriverAdapterCPDS and Jdbc2PoolDataSource(Factory)
to implement javax.naming.Referenceable?
As I understand Tomcat JNDI resource infrastructure, it is enough
to have an object that implements javax.naming.spi.ObjectFactory
As I understand Referencealbe interface on an object is needed
if we want to
* first create an object manually
* then do .getReference() on it
* then bind this reference to a JNDI context
It looks like the Tomcat usage scenario is different.
As I understand
http://jakarta.apache.org/tomcat/tomcat-4.0-doc/jndi-resources-howto.html
it is
* we configure ResourceParameters section in server.xml (or whatever)
* at runtime Tomcat creates an object of the class named
as 'factory' in those parameters and casts it to the
ObjectFactoryInterface
* when an instance is needed
getObjectInstance() is invoked on those, the first
parameter containing the set of properties configured
under ResrouceParameters
I would have nothing against implementing Referenceable by
if it was coming for free to us.
But this is not the case.
Jdbc2DataSource had to go into greatest quirks and tricks
because of this. I would even say that this has determined
its design and that it has made this design overcomplicated.
The trouble is this:
with a DataSource factory we need the client to receive
always the same object from the lookup() method.
So this is a trivial factory, it always creates the same
object.
We could bind the object directly into JNDI, but Tomcat
does allow us only the factory approach,
Okay, so good so far.
But, if this only object that is created with the factory
is Referenceable, it has to implement .getReference()
such that factory.getObjectInstance( reference, ... )
would return the same instance.
It would be trivial - as the factory always returns one
object, but the trouble is that the code in Jdbc2PoolDataSource
for some reason fears that two factory instances will be
created at runtime.
If this really happens we need to embed the object itself
into the reference... ufff...
Well, it's got messy.
But so is the code in Jdbc2DataSource.
So, can we enlighten our burden and just nuke Referenceable
from Jdbc2DataSource?
The usage scenario it supports seems not be used in practice.
I have not studied DriverAdapterCPDS to see how it handles
the Referenceable interface. Probably it just records all
the config data there to reconstruct the original Reference
with which it has been created and thus allows its own clone
to be created. As DriverAdapterCPDS does not pool connections
itself, having two identically configured DriverAdapterCPDS
does not cause the troubles that having two identically
configured Jdbc2PoolDataSource would. But while it does
not seem to create dramatical trouble it does not give
any advantage in my view either.
Maybe nuke Referenceable from it altogether?
BTW it looks like DriverAdapterCPDS was created first
and the Referenceable implementing code was just copied
from it to the Jdbc2PoolDataSource. So probably it is
a code that does the right thing (tm :) in Jdbc2PoolDataSource
anyway.
Thoughts?
-Anton
(And sorry for the message being quite messy itself -- really
have got to run right now)
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
