Re: cvs commit:jakarta-turbine-torque/proposals/jdbc2pool/org/apache/torque/jdbc2po ol/adapter ConnectionImpl.java PooledConnectionDataSource.javaPooledConnectionImpl.java

[Jason van Zyl <jv...@apache.org>]

On 8/15/01 5:28 PM, "John McNally" <jm...@collab.net> wrote:

> It would certainly be best to use and develop a single connection pool.
> I would not say the commons pool is jdbc2 compliant and it is more
> complicated than ours.  A jdbc2 pool would use
> PooledConnectionDataSource as its backend supply of connections and it
> would use jndi to support the plugging in of the
> PooledConnectionDataSource.

Fair enough, like I said I haven't used the one in the commons and it was a
suggestion but there is also the connection pool in struts which I believe
uses a DataSources.
 
> Our connection pool is essentially two classes. The pool and the service
> front end.  I was just swapping the service front end for a DataSource.
> The service could still be useful in initializing the pool, but a jdbc2
> pool is supposed to use standard property names so that it can be
> plugged in and configured by applications/servers when they bind the
> pool to jndi.  There is still a bit of work to do towards this in the
> code I have dumped into the proposals directory.
> 
> The other 3 classes I submitted are code that would normally be provided
> by a jdbc2 driver.  They compose the backend the database/jdbc vendor
> provides to allow connections to be pooled by a jdbc2 compliant
> connection pool.  These can be used for db's that have not yet
> implemented the interfaces.
> 
> I could be wrong but I saw nothing of this in the commons pool and it is
> much harder for me to understand since it has about 5x as many classes.
> 
> What I am really after is to move torque to use a jdbc2 compliant pool,
> so that the pool can be swapped for another one, in the event our
> simple, performant pool is not adequate for some application.  Since I
> did not see a valid alternative I started porting our pool to the new
> interfaces.  I was hoping for some help in creating the new pool as I am
> sure there are other turbine users who understand the spec better than I
> and it is not even the part that I am the most interested in.

If you just want a compliant pool than the struts one will probababy work,
and Craig is always pretty helpful and could tell you in five seconds
whether it is what you want. There is also PoolMan which is supposed to be
very good (I believe it's used in Jrun and Geir knows more probably) and the
lic is compatible I believe.
 
> john mcnally
> 
> 
> Jason van Zyl wrote:
>> 
>> On 8/15/01 2:17 PM, "Jon Stevens" <jo...@latchkey.com> wrote:
>> 
>>> on 8/15/01 10:50 AM, "Jason van Zyl" <jv...@apache.org> wrote:
>>> 
>>>> How about working with the DBCP code that exists in the commons, I believe
>>>> it is already JDBC2 and it has a thorough set of tests already.
>>> 
>>> So, we should up an drop the pool that we have spent years writing and
>>> debugging, or should we upgrade our pool to support the latest JDBC API's?
>> 
>> I said work with, and it's a suggestion. Take the best of the pool we have
>> and integrate it into one tool that we can all use. But I would also add
>> that any tool with a complete set of tests trumps a tool without.
>> 
>> If there are glitches in the connection pool we have, which is not unlikely
>> because there is no testbed and no one has ever done any sort of load/stress
>> testing or has never published the results, than those bugs are going to be
>> propagated into the next one.
>> 
>> I have not used the commons connection pool, but something that is so highly
>> used and necessary as a connection pool should have thorough tests and I
>> would say that we don't need four of them lying around jakarta.
>> 
>> I am also in full favour of culling code when a well tested alternative is
>> available. Rodney has probably worked as long on his connection pool as we
>> have on ours and he's got tests so if I was pushed for an answer I would say
>> torque should be made to have pluggable connection pools and the less robust
>> connection pool should be culled and I would venture so say that from the
>> coupling I've seen in ours and the lack of tests that ours is the less
>> robust one. I would feel differently if we had tests, I would probably fight
>> for ours.
>> 
>> Just the same as we could probably use bean utils in our PP classes,
>> velocity use a standard introspector, that our pooling service could use the
>> pooling code in the commons, that torque should use the digester ... I just
>> feel there's more important things to do than make another connection pool.
>> 
>>> -jon
>>> 
>>> 
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
>>> For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
>> 
>> --
>> 
>> jvz.
>> 
>> Jason van Zyl
>> 
>> http://tambora.zenplex.org
>> http://jakarta.apache.org/turbine
>> http://jakarta.apache.org/velocity
>> http://jakarta.apache.org/alexandria
>> http://jakarta.apache.org/commons
>> 
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: turbine-dev-help@jakarta.apache.org

-- 

jvz.

Jason van Zyl

http://tambora.zenplex.org
http://jakarta.apache.org/turbine
http://jakarta.apache.org/velocity
http://jakarta.apache.org/alexandria
http://jakarta.apache.org/commons



---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org