commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Thomas <ma...@apache.org>
Subject Re: [POOL2] [Keyed]ObjectPoolFactory mutability and DBCP/JNDI
Date Wed, 14 Dec 2011 18:23:45 GMT
On 14/12/2011 17:27, sebb wrote:
> On 14 December 2011 17:01, Mark Thomas <markt@apache.org> wrote:
>> On 14/12/2011 09:23, sebb wrote:
>>> I'm trying to establish the mutability needs of the
>>> [Keyed]ObjectPoolFactory implementations, i.e.
>>>
>>> Generic[Keyed]ObjectPoolFactory
>>>
>>> I've looked at DBCP 1.4, which uses POOL 1.x.
>>
>> You need to look at DBCP trunk that uses POOL 2. There has been quite a
>> lot of refactoring.
> 
> Yes, but 1.4 shows how factories have been historically used.
> AFAIK, DBCP2 has yet to be used in the field.
> 
>>> DBCP 1.4 currently creates an instance of
>>> GenericKeyedObjectPoolFactory, which it then uses via the interface
>>> KeyedObjectPoolFactory.
>>> [This is in the class BasicDataSource.]
>>> The additional GKOPF getters, and the protected mutable variables are
>>> not actually used by DBCP; it only needs to create the instance of
>>> KeyedObjectPoolFactory.
>>> There is no indication that DBCP needs to change or even inspect the
>>> factory settings once it is created.
>>>
>>> The factory setters were added in POOL2; if they were not needed for
>>> DBCP in POOL 1.X, so are they really needed in POOL 2.x?
>>>
>>> I already removed them as part of making the classes thread-safe; the
>>> question is, are the setters now needed in POOL 2?
>>> If so, they can be restored, but synch./volatile will need to be
>>> added, as I assume the factories must be thread-safe.
>>>
>>> Indeed, are the getters even needed? The Pool 1.x code did provide
>>> getters, but AFAICT they were not used by DBCP.
>>>
>>> The calling code knows what it used to create the factory, and the
>>> factory is subsequently used as an instance of the interface - which
>>> only provides the createPool() method.
>>> Is there really a need for other code to find out what the original
>>> factory settings were?
>>>
>>> Can the getters be removed?
>>> Do the setters have to be restored?
>>
>> The factory is little more than a wrapper for the G[K]OPConfig and
>> [K]PoolableObjectFactory.
>>
>> I think there are three options.
>> 1. Drop getters and setters and keep it as a simple, immutable wrapper.
>> 2. Provide getters and setters and make it thread-safe for folks who
>> want multiple pools with almost identical configuration.
>> 3. Drop the Factory entirely.
>>
>> Observations:
>> DBCP2 doesn't need these factories.
>> The factories aren't adding very much value.
> 
> Indeed.
> 
>> Conclusions:
>> On reflection, I am leaning towards dropping these factories entirely.
> 
> I did wonder about that as well; in which case the interfaces can
> presumably be dropped too.
> 
> My preference order is: 3 or 1, else 2.

Assuming there are no objections I'll commit the removal of the
factories and the interfaces some time tomorrow.

Mark

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


Mime
View raw message