commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Quinton McCombs" <qmcco...@nequalsone.com>
Subject RE: [pool] GenericObjectPool subclass
Date Fri, 07 Mar 2003 19:51:04 GMT
I think that a public addObject() method should be created.  Using
returnObject() to populate the pool just does not make sense.  Part of
the contract is that you can only return objects that have been
borrowed.  Without a factory, the only way to get objects into the pool
is to go against the contract.

To maintain a min number of idle instances in your pool, you could have
a separate thread monitor the result of getNumIdle().  When it drops
below a certain level, use addObject() (assuming this method is added)
to add objects until there are enough.

I would suggest that if you want the addObject() method sooner than
later, submit a patch....  :-)

> -----Original Message-----
> From: Lee Breisacher [mailto:LBreisacher@seagullsw.com] 
> Sent: Friday, March 07, 2003 12:11 PM
> To: commons-user@jakarta.apache.org
> Subject: [pool] GenericObjectPool subclass
> 
> 
> I recently ran into a problem with commons-pool v1.0.1 which 
> is fixed in the latest CVS revisions. Good news. However, 
> with 1.0.1 I have a subclass of GenericObjectPool that 
> directly accesses a couple instance fields (details
> below) that no longer compiles because the latest CVS 
> revision of GenericObjectPool has changed all the instance 
> fields to be private.  I'm hoping someone here has a suggestion...
> 
> A little background first:  The objects that I'm keeping in a 
> pool are quite time-consuming to create. The application that 
> the pool lives in expects the pooled objects to be available 
> "right away" (as much as possible), so we have the notion of 
> pre-creating several objects and putting them in the pool 
> during application startup. In fact, I invented the notion of 
> a pool with a "minimum idle count" - the pool always has at 
> least "minIdle" objects in it. When an object is borrowed, a 
> background filler thread back-fills the pool with new objects.
> 
> The way I did this (using commons-pool 1.0.1) is by 
> subclassing GenericObjectPool and doing some "clever" tricks 
> involving direct access to the _factory and _numActive fields 
> (see code below). Now I see that in the latest revisions 
> those fields have been made private so my code no longer compiles. 
> 
> So, I'm scratching my head trying to figure out a way to do 
> this.  I've tried this seemingly obvious approach:  When a 
> pool is created, call
> borrowObject() a few times to pre-create some objects, then 
> immediately
> returnObject() each of them.  This actually works for 
> pre-filling the pool, but doesn't work so well for keeping 
> the pool filled after "real" borrowObject()s have been done 
> -- say we want the pool to always have 4 objects available 
> (minIdle=4), so we put 4 in at the start. Now a couple real 
> borrows are done, so there's 2 left. Now we try to re-fill 
> back up to 4 by doing borrowObject(), but alas that simply 
> returns one of the remaining 2 objects instead of creating a 
> new one. I think you see the problem.
> 
> Any suggestions would be most welcome. FWIW, here's the code 
> that I have in my GenericObjectPool subclass (that no longer 
> compiles):
> 
> 	protected void checkMinIdle() throws Exception {
> 		while( this.needsFilling() ) {
> 			// Create one, then immediately return it to the
> pool.
> 			Object obj = _factory.makeObject();
> 			synchronized(this) {
> 				_numActive++;	// A little 
> slimy - must do
> this because returnObject decrements it.
> 				this.returnObject(obj);
> 			}
> 		}
> 	}
> 
> Perhaps one of the "owners" of commons-pool could add a protected
> getFactory() method and a protected incrementNumActive() 
> method, or perhaps provide a protected addObject(obj) method 
> that does the same thing as
> returnObject() but does not decrement _numActive?
> 
> Thanks,
> 
> Lee
> 

Mime
View raw message