You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by sebb <se...@gmail.com> on 2011/12/14 13:10:52 UTC
[POOL2] mutability requirements for Generic[Keyed]ObjectPool in DBCP/JNDI
This is a parallel thread to the one about PoolFactory implementations.
I'm trying to establish the mutability needs of the
[Keyed]ObjectPool implementations, i.e.
Generic[Keyed]ObjectPool
I've looked at DBCP 1.4, which uses POOL 1.x.
SharedPoolDataSource.registerPool() creates an instance of
GenericKeyedObjectPool which it configures via the setters; however
the instance is then stored in a KeyedObjectPool, and setters/getters
are not used elsewwhere.
SImilarly, DriverAdapterCPDS.getPooledConnection creates an instance
of GenericKeyedObjectPool which is then only used via the
KeyedObjectPool interface.
So: as far as I can tell from DBCP, there is no need to provide
mutable ObjectPool implementations; so long as the pool can be
configured intially, that is sufficient.
Are there any other existing use cases that I am missing here?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [POOL2] mutability requirements for Generic[Keyed]ObjectPool
in DBCP/JNDI
Posted by Phil Steitz <ph...@gmail.com>.
On 12/14/11 5:10 AM, sebb wrote:
> This is a parallel thread to the one about PoolFactory implementations.
>
> I'm trying to establish the mutability needs of the
> [Keyed]ObjectPool implementations, i.e.
>
> Generic[Keyed]ObjectPool
>
> I've looked at DBCP 1.4, which uses POOL 1.x.
>
> SharedPoolDataSource.registerPool() creates an instance of
> GenericKeyedObjectPool which it configures via the setters; however
> the instance is then stored in a KeyedObjectPool, and setters/getters
> are not used elsewwhere.
>
> SImilarly, DriverAdapterCPDS.getPooledConnection creates an instance
> of GenericKeyedObjectPool which is then only used via the
> KeyedObjectPool interface.
>
> So: as far as I can tell from DBCP, there is no need to provide
> mutable ObjectPool implementations; so long as the pool can be
> configured intially, that is sufficient.
>
> Are there any other existing use cases that I am missing here?
My email access is going to be choppy next couple of days, so I may
not respond quickly, but have a look in the not too distant archives
for discussion around setFactory. Look at the code that associates
a connection pool with a datasource and recent discussion of that code.
Phil
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [POOL2] mutability requirements for Generic[Keyed]ObjectPool in DBCP/JNDI
Posted by ma...@apache.org.
sebb <se...@gmail.com> wrote:
>This is a parallel thread to the one about PoolFactory implementations.
>
>I'm trying to establish the mutability needs of the
>[Keyed]ObjectPool implementations, i.e.
>
>Generic[Keyed]ObjectPool
>
>I've looked at DBCP 1.4, which uses POOL 1.x.
>
>SharedPoolDataSource.registerPool() creates an instance of
>GenericKeyedObjectPool which it configures via the setters; however
>the instance is then stored in a KeyedObjectPool, and setters/getters
>are not used elsewwhere.
>
>SImilarly, DriverAdapterCPDS.getPooledConnection creates an instance
>of GenericKeyedObjectPool which is then only used via the
>KeyedObjectPool interface.
>
>So: as far as I can tell from DBCP, there is no need to provide
>mutable ObjectPool implementations; so long as the pool can be
>configured intially, that is sufficient.
>
>Are there any other existing use cases that I am missing here?
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>For additional commands, e-mail: dev-help@commons.apache.org
Yes,
There is a requirement to modify the pool configuration via jmx while the pool is in use.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [POOL2] mutability requirements for Generic[Keyed]ObjectPool in DBCP/JNDI
Posted by sebb <se...@gmail.com>.
On 15 December 2011 08:26, Mark Thomas <ma...@apache.org> wrote:
> On 14/12/2011 23:12, sebb wrote:
>> On 14 December 2011 22:22, Mark Thomas <ma...@apache.org> wrote:
>>> On 14/12/2011 19:12, sebb wrote:
>>>> On 14 December 2011 18:29, Mark Thomas <ma...@apache.org> wrote:
>>>>> JNDI assumes resources are essentially beans i.e. have zero argument
>>>>> constructors and getters/setters. If this is not the case then some
>>>>> extra plumbing is required. The further G[K]OP gets from a JavaBean the
>>>>> more plumbing required. Currently the only extra plumbing required is to
>>>>> work-around the zero-argument constructor. Removing the setters would
>>>>> mean more plumbing would be required for someone to create a custom JNDI
>>>>> resource for a pool of objects of type X.
>>>>
>>>> But AFAIK JNDI does not allow dynamic changes, so can operate on the
>>>> config classes - which do have the required characteristics, AFAICT.
>>>
>>> Which is what I mean by "more plumbing". Given that DBCP users want to
>>> change pool config on the fly, I imagine users of other pools will to.
>>
>> I was just observing that the mutability requirements don't come from JNDI.
>> Whether JNDI updates the config class or a mutable pool makes little
>> or no difference to the code required.
>
> It makes little difference to the calling code, but the non-mutable
> attributes adds the requirement for a config class (plumbing) and
> something to inject the config before first use since JNDI resources
> don't have standard start/stop methods that the contain can call (more
> plumbing). If the resource is a bean, none of this plumbing is required.
>
>>>>> Given that there is a requirement from DBCP users for dynamic changes to
>>>>> the pool, I believe POOL2 needs to support mutable pool implementations.
>>>>
>>>> The more mutable fields there are, the more work to be done to ensure
>>>> thread-safety, and the more checking/unit tests needed when updating
>>>> the code.
>>>>
>>>> So - are there any settings that it does not make sense to mutate
>>>> after creation?
>>>>
>>>> For example, LIFO?
>>> May as well be mutable.
>>
>> Might create some interesting logic issues if it changes whilst a one
>> thread is using the pool and then another thread uses the new value.
>
> Possibly. We'll have to see. I can't think of any right now given the
> implementation.
>
>>>> jmxEnabled/jmxNamePrefix?
>>> That can / should be fixed.
>>
>> Does that mean set at instantiation only, or don't allow any changes
>> once the pool starts to be used?
>
> Instantiation, since it needs to constant so it can be managed via JMX.
Actually, that is done already.
I'd got the names from the config class, and forgot to check if it was
stored in the pool classes - they're not, they're used in the ctor
only.
Sorry for the noise, however there just might be other fields that
should be set in the ctor.
>> Similarly for any other non-mutable items - the values must be
>> established before they are first used.
>>
>> Could do this by disabling the setter if the pool is active.
>>
>> Or check for actual first use in the getter, but much easier to
>> control if the field is final (i.e. set at construction).
>
> Using final would be my preference.
>
>>>> testOnBorrow/testOnReturn/testWhileIdle?
>>> Mutable.
>>>
>>>> blockWhenExhausted?
>>> Mutable.
>>>
>>>> And are there settings which need to be constrained relative to other settings?
>>> No. We don't do this currently and I don't see a need to start. There
>>> are some combinations that don't make much sense but we don't enforce
>>> anything.
>>
>> OK, makes it simpler.
>
> Indeed :)
>
>>>> Would it make sense to only allow changes via the config class?
>>> No. The config class can be a short-cut but I don't think it is the only
>>> way. Note that changes via a config class won't be atomic unless we make
>>> some changes.
>>>> This would simplify the classes by eliminating all the setters, and
>>>> should make consistency checking easier.
>>> I don't think we need consistency checking.
>>>
>>> My current thinking is:
>>> - make all mutable attributes volatile
>>
>> Yes.
>>
>>> - methods take local copies of the attributes they require at the start
>>> of the method to ensure consistency
>>
>> That will ensure consistency within a method.
>>
>> It's not yet clear if there are any independent methods that rely on
>> consistency between them.
>
> I don't believe that is the case.
>
> There is some work to do to check that this is currently how all the
> methods are implemented. Now all access is via getters, checking that
> getters are called at most once per method should be relatively easy.
>
>> Also if non-private method A calls non-private method B and they both
>> need the same field, there's a potential window where the value could
>> change unless special precautions are taken. It would be very easy to
>> accidentally break the rule of only fetching each item once within a
>> method invocation.
>
> That needs careful checking. I have been thinking about how we might
> refactor things to avoid this entirely but haven't found an acceptable
> solution yet.
If all private methods were static, they could only access fields via
parameters; that might help somewhat to ensure fetch-once behaviour.
Probably a bit much to convert all non-private methods into simple
wrappers for static private methods, but it would solve the issue.
> Mark
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [POOL2] mutability requirements for Generic[Keyed]ObjectPool
in DBCP/JNDI
Posted by Mark Thomas <ma...@apache.org>.
On 14/12/2011 23:12, sebb wrote:
> On 14 December 2011 22:22, Mark Thomas <ma...@apache.org> wrote:
>> On 14/12/2011 19:12, sebb wrote:
>>> On 14 December 2011 18:29, Mark Thomas <ma...@apache.org> wrote:
>>>> JNDI assumes resources are essentially beans i.e. have zero argument
>>>> constructors and getters/setters. If this is not the case then some
>>>> extra plumbing is required. The further G[K]OP gets from a JavaBean the
>>>> more plumbing required. Currently the only extra plumbing required is to
>>>> work-around the zero-argument constructor. Removing the setters would
>>>> mean more plumbing would be required for someone to create a custom JNDI
>>>> resource for a pool of objects of type X.
>>>
>>> But AFAIK JNDI does not allow dynamic changes, so can operate on the
>>> config classes - which do have the required characteristics, AFAICT.
>>
>> Which is what I mean by "more plumbing". Given that DBCP users want to
>> change pool config on the fly, I imagine users of other pools will to.
>
> I was just observing that the mutability requirements don't come from JNDI.
> Whether JNDI updates the config class or a mutable pool makes little
> or no difference to the code required.
It makes little difference to the calling code, but the non-mutable
attributes adds the requirement for a config class (plumbing) and
something to inject the config before first use since JNDI resources
don't have standard start/stop methods that the contain can call (more
plumbing). If the resource is a bean, none of this plumbing is required.
>>>> Given that there is a requirement from DBCP users for dynamic changes to
>>>> the pool, I believe POOL2 needs to support mutable pool implementations.
>>>
>>> The more mutable fields there are, the more work to be done to ensure
>>> thread-safety, and the more checking/unit tests needed when updating
>>> the code.
>>>
>>> So - are there any settings that it does not make sense to mutate
>>> after creation?
>>>
>>> For example, LIFO?
>> May as well be mutable.
>
> Might create some interesting logic issues if it changes whilst a one
> thread is using the pool and then another thread uses the new value.
Possibly. We'll have to see. I can't think of any right now given the
implementation.
>>> jmxEnabled/jmxNamePrefix?
>> That can / should be fixed.
>
> Does that mean set at instantiation only, or don't allow any changes
> once the pool starts to be used?
Instantiation, since it needs to constant so it can be managed via JMX.
> Similarly for any other non-mutable items - the values must be
> established before they are first used.
>
> Could do this by disabling the setter if the pool is active.
>
> Or check for actual first use in the getter, but much easier to
> control if the field is final (i.e. set at construction).
Using final would be my preference.
>>> testOnBorrow/testOnReturn/testWhileIdle?
>> Mutable.
>>
>>> blockWhenExhausted?
>> Mutable.
>>
>>> And are there settings which need to be constrained relative to other settings?
>> No. We don't do this currently and I don't see a need to start. There
>> are some combinations that don't make much sense but we don't enforce
>> anything.
>
> OK, makes it simpler.
Indeed :)
>>> Would it make sense to only allow changes via the config class?
>> No. The config class can be a short-cut but I don't think it is the only
>> way. Note that changes via a config class won't be atomic unless we make
>> some changes.
>>> This would simplify the classes by eliminating all the setters, and
>>> should make consistency checking easier.
>> I don't think we need consistency checking.
>>
>> My current thinking is:
>> - make all mutable attributes volatile
>
> Yes.
>
>> - methods take local copies of the attributes they require at the start
>> of the method to ensure consistency
>
> That will ensure consistency within a method.
>
> It's not yet clear if there are any independent methods that rely on
> consistency between them.
I don't believe that is the case.
There is some work to do to check that this is currently how all the
methods are implemented. Now all access is via getters, checking that
getters are called at most once per method should be relatively easy.
> Also if non-private method A calls non-private method B and they both
> need the same field, there's a potential window where the value could
> change unless special precautions are taken. It would be very easy to
> accidentally break the rule of only fetching each item once within a
> method invocation.
That needs careful checking. I have been thinking about how we might
refactor things to avoid this entirely but haven't found an acceptable
solution yet.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [POOL2] mutability requirements for Generic[Keyed]ObjectPool in DBCP/JNDI
Posted by sebb <se...@gmail.com>.
On 14 December 2011 22:22, Mark Thomas <ma...@apache.org> wrote:
> On 14/12/2011 19:12, sebb wrote:
>> On 14 December 2011 18:29, Mark Thomas <ma...@apache.org> wrote:
>>> JNDI assumes resources are essentially beans i.e. have zero argument
>>> constructors and getters/setters. If this is not the case then some
>>> extra plumbing is required. The further G[K]OP gets from a JavaBean the
>>> more plumbing required. Currently the only extra plumbing required is to
>>> work-around the zero-argument constructor. Removing the setters would
>>> mean more plumbing would be required for someone to create a custom JNDI
>>> resource for a pool of objects of type X.
>>
>> But AFAIK JNDI does not allow dynamic changes, so can operate on the
>> config classes - which do have the required characteristics, AFAICT.
>
> Which is what I mean by "more plumbing". Given that DBCP users want to
> change pool config on the fly, I imagine users of other pools will to.
I was just observing that the mutability requirements don't come from JNDI.
Whether JNDI updates the config class or a mutable pool makes little
or no difference to the code required.
>>> Given that there is a requirement from DBCP users for dynamic changes to
>>> the pool, I believe POOL2 needs to support mutable pool implementations.
>>
>> The more mutable fields there are, the more work to be done to ensure
>> thread-safety, and the more checking/unit tests needed when updating
>> the code.
>>
>> So - are there any settings that it does not make sense to mutate
>> after creation?
>>
>> For example, LIFO?
> May as well be mutable.
Might create some interesting logic issues if it changes whilst a one
thread is using the pool and then another thread uses the new value.
>> jmxEnabled/jmxNamePrefix?
> That can / should be fixed.
Does that mean set at instantiation only, or don't allow any changes
once the pool starts to be used?
Similarly for any other non-mutable items - the values must be
established before they are first used.
Could do this by disabling the setter if the pool is active.
Or check for actual first use in the getter, but much easier to
control if the field is final (i.e. set at construction).
>> testOnBorrow/testOnReturn/testWhileIdle?
> Mutable.
>
>> blockWhenExhausted?
> Mutable.
>
>> And are there settings which need to be constrained relative to other settings?
> No. We don't do this currently and I don't see a need to start. There
> are some combinations that don't make much sense but we don't enforce
> anything.
OK, makes it simpler.
>> Would it make sense to only allow changes via the config class?
> No. The config class can be a short-cut but I don't think it is the only
> way. Note that changes via a config class won't be atomic unless we make
> some changes.
>> This would simplify the classes by eliminating all the setters, and
>> should make consistency checking easier.
> I don't think we need consistency checking.
>
> My current thinking is:
> - make all mutable attributes volatile
Yes.
> - methods take local copies of the attributes they require at the start
> of the method to ensure consistency
That will ensure consistency within a method.
It's not yet clear if there are any independent methods that rely on
consistency between them.
Also if non-private method A calls non-private method B and they both
need the same field, there's a potential window where the value could
change unless special precautions are taken. It would be very easy to
accidentally break the rule of only fetching each item once within a
method invocation.
> Mark
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [POOL2] mutability requirements for Generic[Keyed]ObjectPool
in DBCP/JNDI
Posted by Mark Thomas <ma...@apache.org>.
On 14/12/2011 19:12, sebb wrote:
> On 14 December 2011 18:29, Mark Thomas <ma...@apache.org> wrote:
>> JNDI assumes resources are essentially beans i.e. have zero argument
>> constructors and getters/setters. If this is not the case then some
>> extra plumbing is required. The further G[K]OP gets from a JavaBean the
>> more plumbing required. Currently the only extra plumbing required is to
>> work-around the zero-argument constructor. Removing the setters would
>> mean more plumbing would be required for someone to create a custom JNDI
>> resource for a pool of objects of type X.
>
> But AFAIK JNDI does not allow dynamic changes, so can operate on the
> config classes - which do have the required characteristics, AFAICT.
Which is what I mean by "more plumbing". Given that DBCP users want to
change pool config on the fly, I imagine users of other pools will to.
>> Given that there is a requirement from DBCP users for dynamic changes to
>> the pool, I believe POOL2 needs to support mutable pool implementations.
>
> The more mutable fields there are, the more work to be done to ensure
> thread-safety, and the more checking/unit tests needed when updating
> the code.
>
> So - are there any settings that it does not make sense to mutate
> after creation?
>
> For example, LIFO?
May as well be mutable.
> jmxEnabled/jmxNamePrefix?
That can / should be fixed.
> testOnBorrow/testOnReturn/testWhileIdle?
Mutable.
> blockWhenExhausted?
Mutable.
> And are there settings which need to be constrained relative to other settings?
No. We don't do this currently and I don't see a need to start. There
are some combinations that don't make much sense but we don't enforce
anything.
> Would it make sense to only allow changes via the config class?
No. The config class can be a short-cut but I don't think it is the only
way. Note that changes via a config class won't be atomic unless we make
some changes.
> This would simplify the classes by eliminating all the setters, and
> should make consistency checking easier.
I don't think we need consistency checking.
My current thinking is:
- make all mutable attributes volatile
- methods take local copies of the attributes they require at the start
of the method to ensure consistency
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [POOL2] mutability requirements for Generic[Keyed]ObjectPool in DBCP/JNDI
Posted by Gary Gregory <ga...@gmail.com>.
On Dec 14, 2011, at 14:12, sebb <se...@gmail.com> wrote:
> On 14 December 2011 18:29, Mark Thomas <ma...@apache.org> wrote:
>> On 14/12/2011 12:10, sebb wrote:
>>> This is a parallel thread to the one about PoolFactory implementations.
>>>
>>> I'm trying to establish the mutability needs of the
>>> [Keyed]ObjectPool implementations, i.e.
>>>
>>> Generic[Keyed]ObjectPool
>>>
>>> I've looked at DBCP 1.4, which uses POOL 1.x.
>>>
>>> SharedPoolDataSource.registerPool() creates an instance of
>>> GenericKeyedObjectPool which it configures via the setters; however
>>> the instance is then stored in a KeyedObjectPool, and setters/getters
>>> are not used elsewwhere.
>>>
>>> SImilarly, DriverAdapterCPDS.getPooledConnection creates an instance
>>> of GenericKeyedObjectPool which is then only used via the
>>> KeyedObjectPool interface.
>>>
>>> So: as far as I can tell from DBCP, there is no need to provide
>>> mutable ObjectPool implementations; so long as the pool can be
>>> configured intially, that is sufficient.
>>>
>>> Are there any other existing use cases that I am missing here?
>>
>> I do see periodic requests to be able to change the (DBCP) pool
>> properties dynamically and it was my intention to support this use case
>> via JMX for POOL2.
>
> Ah - that is a new requirement.
>
>> JNDI assumes resources are essentially beans i.e. have zero argument
>> constructors and getters/setters. If this is not the case then some
>> extra plumbing is required. The further G[K]OP gets from a JavaBean the
>> more plumbing required. Currently the only extra plumbing required is to
>> work-around the zero-argument constructor. Removing the setters would
>> mean more plumbing would be required for someone to create a custom JNDI
>> resource for a pool of objects of type X.
>
> But AFAIK JNDI does not allow dynamic changes, so can operate on the
> config classes - which do have the required characteristics, AFAICT.
>
>> DBCP already has the plumbing to handle the removal of the setters but
>> it would require some code changes.
>
> I committed a fix earlier today which changed the one remaining class
> that used setters on the pool so it now uses setters on the config
> class.
> The other pool creation classes already did that.
> AFAICT, DBCP2 does not need to use setters on the pool at present.
>
>> It was always my intention to provide the ability to change the pool
>> properties on the fly. I would rather spend a little time fixing the
>> remaining threading issues than drop that requirement. I certainly don't
>> want to try coding DBCP to support dynamic changes when the underlying
>> pool does not.
>
> That is a new requirement on DBCP (of which I was previously unaware)
> - and does of course change things.
>
>> Given that there is a requirement from DBCP users for dynamic changes to
>> the pool, I believe POOL2 needs to support mutable pool implementations.
>
> The more mutable fields there are, the more work to be done to ensure
> thread-safety, and the more checking/unit tests needed when updating
> the code.
>
> So - are there any settings that it does not make sense to mutate
> after creation?
>
> For example, LIFO?
> jmxEnabled/jmxNamePrefix?
> testOnBorrow/testOnReturn/testWhileIdle?
> blockWhenExhausted?
>
> And are there settings which need to be constrained relative to other settings?
> For example some of the counts probably have inter-dependent ranges.
> If so, then where is the validation going to be done?
>
> Would it make sense to only allow changes via the config class?
I should then be able to get a config object from a pool, tweak it,
and pass it back.
Gary
>
> This would simplify the classes by eliminating all the setters, and
> should make consistency checking easier.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [POOL2] mutability requirements for Generic[Keyed]ObjectPool in DBCP/JNDI
Posted by sebb <se...@gmail.com>.
On 14 December 2011 18:29, Mark Thomas <ma...@apache.org> wrote:
> On 14/12/2011 12:10, sebb wrote:
>> This is a parallel thread to the one about PoolFactory implementations.
>>
>> I'm trying to establish the mutability needs of the
>> [Keyed]ObjectPool implementations, i.e.
>>
>> Generic[Keyed]ObjectPool
>>
>> I've looked at DBCP 1.4, which uses POOL 1.x.
>>
>> SharedPoolDataSource.registerPool() creates an instance of
>> GenericKeyedObjectPool which it configures via the setters; however
>> the instance is then stored in a KeyedObjectPool, and setters/getters
>> are not used elsewwhere.
>>
>> SImilarly, DriverAdapterCPDS.getPooledConnection creates an instance
>> of GenericKeyedObjectPool which is then only used via the
>> KeyedObjectPool interface.
>>
>> So: as far as I can tell from DBCP, there is no need to provide
>> mutable ObjectPool implementations; so long as the pool can be
>> configured intially, that is sufficient.
>>
>> Are there any other existing use cases that I am missing here?
>
> I do see periodic requests to be able to change the (DBCP) pool
> properties dynamically and it was my intention to support this use case
> via JMX for POOL2.
Ah - that is a new requirement.
> JNDI assumes resources are essentially beans i.e. have zero argument
> constructors and getters/setters. If this is not the case then some
> extra plumbing is required. The further G[K]OP gets from a JavaBean the
> more plumbing required. Currently the only extra plumbing required is to
> work-around the zero-argument constructor. Removing the setters would
> mean more plumbing would be required for someone to create a custom JNDI
> resource for a pool of objects of type X.
But AFAIK JNDI does not allow dynamic changes, so can operate on the
config classes - which do have the required characteristics, AFAICT.
> DBCP already has the plumbing to handle the removal of the setters but
> it would require some code changes.
I committed a fix earlier today which changed the one remaining class
that used setters on the pool so it now uses setters on the config
class.
The other pool creation classes already did that.
AFAICT, DBCP2 does not need to use setters on the pool at present.
> It was always my intention to provide the ability to change the pool
> properties on the fly. I would rather spend a little time fixing the
> remaining threading issues than drop that requirement. I certainly don't
> want to try coding DBCP to support dynamic changes when the underlying
> pool does not.
That is a new requirement on DBCP (of which I was previously unaware)
- and does of course change things.
> Given that there is a requirement from DBCP users for dynamic changes to
> the pool, I believe POOL2 needs to support mutable pool implementations.
The more mutable fields there are, the more work to be done to ensure
thread-safety, and the more checking/unit tests needed when updating
the code.
So - are there any settings that it does not make sense to mutate
after creation?
For example, LIFO?
jmxEnabled/jmxNamePrefix?
testOnBorrow/testOnReturn/testWhileIdle?
blockWhenExhausted?
And are there settings which need to be constrained relative to other settings?
For example some of the counts probably have inter-dependent ranges.
If so, then where is the validation going to be done?
Would it make sense to only allow changes via the config class?
This would simplify the classes by eliminating all the setters, and
should make consistency checking easier.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [POOL2] mutability requirements for Generic[Keyed]ObjectPool
in DBCP/JNDI
Posted by Mark Thomas <ma...@apache.org>.
On 14/12/2011 12:10, sebb wrote:
> This is a parallel thread to the one about PoolFactory implementations.
>
> I'm trying to establish the mutability needs of the
> [Keyed]ObjectPool implementations, i.e.
>
> Generic[Keyed]ObjectPool
>
> I've looked at DBCP 1.4, which uses POOL 1.x.
>
> SharedPoolDataSource.registerPool() creates an instance of
> GenericKeyedObjectPool which it configures via the setters; however
> the instance is then stored in a KeyedObjectPool, and setters/getters
> are not used elsewwhere.
>
> SImilarly, DriverAdapterCPDS.getPooledConnection creates an instance
> of GenericKeyedObjectPool which is then only used via the
> KeyedObjectPool interface.
>
> So: as far as I can tell from DBCP, there is no need to provide
> mutable ObjectPool implementations; so long as the pool can be
> configured intially, that is sufficient.
>
> Are there any other existing use cases that I am missing here?
I do see periodic requests to be able to change the (DBCP) pool
properties dynamically and it was my intention to support this use case
via JMX for POOL2.
JNDI assumes resources are essentially beans i.e. have zero argument
constructors and getters/setters. If this is not the case then some
extra plumbing is required. The further G[K]OP gets from a JavaBean the
more plumbing required. Currently the only extra plumbing required is to
work-around the zero-argument constructor. Removing the setters would
mean more plumbing would be required for someone to create a custom JNDI
resource for a pool of objects of type X.
DBCP already has the plumbing to handle the removal of the setters but
it would require some code changes.
It was always my intention to provide the ability to change the pool
properties on the fly. I would rather spend a little time fixing the
remaining threading issues than drop that requirement. I certainly don't
want to try coding DBCP to support dynamic changes when the underlying
pool does not.
Given that there is a requirement from DBCP users for dynamic changes to
the pool, I believe POOL2 needs to support mutable pool implementations.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org