commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sebb <>
Subject Re: [POOL2] thread-safety issues
Date Wed, 14 Dec 2011 12:16:52 GMT
On 13 December 2011 20:25, Mark Thomas <> wrote:
> On 13/12/2011 19:12, sebb wrote:
>> I've added some Javadoc to classes to indicate which ones are supposed
>> to be thread-safe and which are not.
>> AFAICT, there remain 2 classes to be dealt with, ie
>> GenericKeyedObjectPool (GKOP)
>> and
>> GenericObjectPool (GOP)
>> GKOP is not currently thread-safe, as there are several mutable
>> variables that aren't always accessed using synch.
>> Adding volatile to these would fix the safe publication issue, but
>> might not fix all thread-safety issues.
>> This depends on how exactly the code uses the variables.
>> If the code relies on the variable not changing between references,
>> then the code is not thread-safe.
>> GOP is not thread-safe either, as the field evictionIterator is not volatile.
>> Adding volatile would ensure safe publication, but the field is
>> accessed multiple times - and may be reset to null.
>> As far as I can tell, the evict() method is not thread-safe because of
>> the way it changes the field.
>> I suspect the code will need to use some synchronisation. Of course
>> the same applies to GKOP.
>> Making all the configuration items final and removing the setters - as
>> discussed previously - will make it much easier to make the classes
>> thread-safe.
>> I think that's the next stage.
> -1. That makes use with DBCP and JNDI much, much harder.

I've looked at the DBCP 1.4 code, and cannot see anywhere that
requires the pools to be re-configured after creation.

Yes the code will have to be changed to set up the Config class before
creating the pool, but that is true anyway.
[Pool2 eliminates multiple ctors with multiple params in favour of the
settable Config class]

Please see other two threads regarding Pool and Factory mutability
where I hope the discussion can continue.

> Lets fix the thread safety issues, being careful to avoid adding syncs
> unless we absolutely have to.
> Mark
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

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

View raw message