commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bugzi...@apache.org
Subject DO NOT REPLY [Bug 31298] New: - setMinIdle feature implemented for GenericKeyedObjectPool
Date Sun, 19 Sep 2004 14:49:07 GMT
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=31298>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=31298

setMinIdle feature implemented for GenericKeyedObjectPool 

           Summary: setMinIdle feature implemented for
                    GenericKeyedObjectPool
           Product: Commons
           Version: 1.2 Final
          Platform: Other
        OS/Version: Other
            Status: NEW
          Severity: Normal
          Priority: Other
         Component: Pool
        AssignedTo: commons-dev@jakarta.apache.org
        ReportedBy: dirk.verbeeck@pandora.be


Patch from Bowler Simon posted on commons-dev (17-19 aug 2004)
---------------------------------------------------------------
The purpose of is to maintain a minimum number idle instances in a pool, but
grow as required up to a maximum number of active instances. The reason for
maintaining a minimum level of idle instances in a pool, is for efficiency. A
call to borrowObject() when there are no pooled instances available, must create
an instance of the object required. This causes delays when the object it is
instanciating needs to reserve resources or connect to remote systems (for
example, an SMTPConnection).

The new class proposed, features the following:

Same features as provided by GenericKeyedObjectPool (idle eviction, validation
of pooled objects on borrow/on return/when idle).

Maintain a minimum number of pooled objects (per key). This number is configurable. 

A seperate thread will be used to periodically create any required objects to
maintain the minimum level. This time period is configurable.

The pool must be aware of a key before it can start maintaining a minimum number
of pooled objects for that key. This can be performed by performing a
borrowObject(key). However, this results in a potential delay whilst the pooled
object is being created. An extra method preparePool(key) is used to give the
pool knowledge of the key, so that it can start maintaining a minimum number of
pooled objects for that key. This should result in a much quicker call to
borrowObject(key), as pooled instances will already be created and waiting in
the pool.

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


Mime
View raw message