Mailing-List: contact dev-help@commons.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Commons Developers List" <dev@commons.apache.org>
Received-SPF: pass (nike.apache.org: domain of phil.steitz@gmail.com
 designates 209.85.212.43 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:user-agent:mime-version:to:subject:references
         :in-reply-to:x-enigmail-version:content-type
         :content-transfer-encoding;
        b=Kp6zYNdtz4vhtX6nsjd+s/WDu37yTxKxzN0gLI+PxXYBx4jiEAWqaA5+aqewjXDzF0
         L5PiHLtS1P4RJnUWWRYEAKUu6d14qJfqTsqH/76bNEEmkjxWwaNwMp2fXCQhkYH1ApD4
         CrdKwp51WrwhzLSRxQNzw3pQ5AF3HYHDW3sXA=
Message-ID: <4C2E917F.9080603@gmail.com>
Date: Fri, 02 Jul 2010 21:25:19 -0400
From: Phil Steitz <phil.steitz@gmail.com>
User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228)
MIME-Version: 1.0
To: Commons Developers List <dev@commons.apache.org>
Subject: Re: [pool] deprecation of setFactory methods
References: <4C28BEAC.9020909@gmail.com>
In-Reply-To: <4C28BEAC.9020909@gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Phil Steitz wrote:
> 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.

Going once, going twice...

Phil
> 
> Phil
> 


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