commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gary Gregory <GGreg...@seagullsoftware.com>
Subject RE: [pool] deprecation of setFactory methods
Date Sat, 03 Jul 2010 01:57:03 GMT
> -----Original Message-----
> From: Phil Steitz [mailto:phil.steitz@gmail.com]
> Sent: Friday, July 02, 2010 18:25
> To: Commons Developers List
> Subject: Re: [pool] deprecation of setFactory methods
> 
> 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...

And gone...

IMO, I see this type of method making more sense when generics are added to the project.

Tangent: If I have a pool of <Widget> (through generics), I can see replacing the factory
with another widget factory. But just saying that I can plug in a new factory that produces
"Object" feels off. It also feels like an advanced feature that can greatly complicate an
implementation: I should be able to define what happens when I plug in a factory (nuke pooled
objects, or don't.) So this might better be handled in a specialized sub-interface.

2c,
Gary

> 
> Phil
> >
> > 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


Mime
View raw message