commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Phil Steitz <phil.ste...@gmail.com>
Subject [pool] deprecation of setFactory methods
Date Mon, 28 Jun 2010 15:24:28 GMT
setFactory belongs to the top level ObjectPool and KeyedObjectPool
interfaces.  I would like to deprecate these methods uniformly (to
be removed in pool 2.0) - removing them from the top level
interfaces and deprecating all implementations. There are two
reasons for this:

1. Good semantics for this method are hard to define.  The interface
docs state only that the method may not always be supported and may
throw RTEs.  GenericObjectPool throws IllegalStateException if the
method is invoked when there are borrowed objects out and destroys
all idle instances as a side effect when it succeeds.  That is a
reasonable approach, but begs the question why not just clear the
existing pool and create a new one.  It seems reasonable to me that
an invariant of an object pool should be instance homogeneity wrt
object factory.  This is what GOP enforces.  So why not just make
the factory immutable?

2. If the factory is mutable, threadsafety requires that access to
it be synchronized.  Currently, we are inconsistent on this.  Adding
synchronization to "fix" this would have significant performance
impacts.

Before proceeding with wholesale deprecation, I would like to get
some feedback.  In particular, I would like to make sure that there
are no valid use cases for setFactory applied to currently
implemented pools. Thanks in advance.

Phil


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


Mime
View raw message