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. Lets fix the thread safety issues, being careful to avoid adding syncs unless we absolutely have to. Mark --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org