commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Thomas <>
Subject [DBCP][POOL] Re-factoring headaches with dbcp2 & pool2
Date Sun, 22 May 2011 21:01:12 GMT

Apologies for the long e-mail. I'll keep it as short as I can.

I am working on dbcp2 alongside pool2, keeping the two in sync as pool2
is refactored. I am currently looking at the removal of the setFactory()
method from G(K)OP and it isn't pretty.

Removing G(K)OP.setFactory() from pool2 is straight forward. Just a few
getFactory() methods to remove from sub-classes and a couple of simple
deletes in the test classes.

The impact on dbcp2 is more problematic. It is ugly for GOP and
significantly worse for GKOP. There are multiple cases in DBCP of
(Keyed)PoolableObjectFactory retaining references to the
(Keyed)ObjectPool they are a factory for. The current approach is to
pass the (Keyed)ObjectPool in to the constructor of the
(Keyed)PoolableObjectFactory and then call setFactory() on the pool.
Removing the setFactory() method makes this impossible.

My first thought was to create the (Keyed)PoolableObjectFactory without
the (Keyed)ObjectPool and then call a setPool() method. This is doable
but it is going to require a lot of changes and I am not sure it is
worth the effort.

The reason the setFactory() is being removed is to make the Factory
immutable. I'm beginning to think that a better approach would be to
keep the setFactory() method but modify it so that it can only be called
once. My current thinking is that calls to setFactory() throw
IllegalStateException if _factory != null. That will need some
double-checked locking to get right but that is safely doable in 1.5

This alternative approach would make my life considerably easier.

Thoughts, comments?



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

View raw message