commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Apache Wiki <wikidi...@apache.org>
Subject [Commons Wiki] Update of "PoolRoadMap" by SimoneTripodi
Date Sun, 05 Dec 2010 13:18:27 GMT
Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Commons Wiki" for change notification.

The "PoolRoadMap" page has been changed by SimoneTripodi.
http://wiki.apache.org/commons/PoolRoadMap?action=diff&rev1=5&rev2=6

--------------------------------------------------

   * any object borrowed from the pool must be returned to the pool. Client code should be
careful to only return a borrowed object once. The same borrowed instance should never be
returned to both returnObject and invalidateObject in one borrow cycle.
   * an object that fails to fails activation, validation, passivation, or is passed to invalidateObject
must be destroyed. Much like the finalize method isn't guarenteed to be called in a deterministic
manner, neither is when the call to destroyObject is to be made strictly specified. For example
a pool could queue objects to be destroyed with a java.util.Timer to help improve the perceived
performance of the pool.
  
+ Configurations:
+  * Make the Config instances immutable and only used as structs for pools ctors;
+  * Some subset of the config properties (need to decide) need to be *individually* mutable
at runtime - e.g., setMaxActive(newMaxActive) needs to remain.  We have agreed at this point
that at least maxActive and maxWait need to be runtime mutable;
+  * Correct functioning of the pool with the current implementation requires that no thread
can change maxActive while another thread holds the lock on the pool's monitor.  Just making
the properties volatile or protecting them with another lock will cause problems;
+  * remove the (pool-synchronized) reconfigure(Config) to enable multiple properties to be
changed atomically;
+  * GOP has the following properties:
+   * numActive
+   * numIdle
+   * maxActive
+   * maxIdle
+   * minIdle
+   * maxWait
+   * whenExhaustedAction
+   * minEvictableIdleTimeMillis
+   * softMinEvictableIdleTimeMillis
+   * testOnBorrow
+   * testOnReturn
+   * testWhileIdle
+   * timeBetweenEvictionRunsMillis
+   * numTestsPerEvictionRun
+   * lifo
+   * factory
+  The first two are initialized at 0 and are read-only.  All of the others are read/write
with default values.  We have decided to deprecate the setter for the factory property and
we have not decided yet which others should be non-final.  Here is the suggested list of properties
that should be runtime mutable:
+   * maxTotal
+   * maxWait
+   * maxIdle
+   * minIdle
+   * idleTimeout
+   * softIdleTimeout
+  Proposal: rename maxActive to maxTotal, since the name is confusing, as it really represents
the limit on the total number of object instances (idle or "active") under management by the
pool. While maxActive does in fact limit numActive, they actually measure different things,
so the names should be different.  The others should be obvious.
+  * GKOP has all of the above properties, but adds
+   * maxTotal
+  and has parameterized properties
+   * numIdle(key)
+   * numActive(key)
+   * maxActive, maxIdle, minIdle are binding per key.
+  Proposal for GKOP
+   * s/maxActive/maxTotalPerKey
+   * s/maxIdle/maxIdlePerKey
+   * s/minIdle/minIdlePerKey
+ 
  === Pool 3 ===
  
  This may break API compatibility for implementations of pools but shouldn't affect client
code using pools. Mostly the exceptions declared in the interfaces that is no longer needed
because of behavior changes in Pool 2 will be removed. This release probably will take advantage
of Java 5 (aka: 1.5) features.

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


Mime
View raw message