New ResourceLimiting Pool for Scratchpad

[Leif Mortenson <le...@silveregg.co.jp>]

I have found that in many cases it was necessary to have a pool of resources which would have an upper limit on the size, like the HardResourceLimitingPool, but would not throw an exception when resources are not available.  The desired functionality was to block until the resource became available.  I found this to be most critical when dealing with JdbcConnectionPools and ThreadPools.



New classes for the org.apache.avalon.excalibur.pool package:
To solve this problem and others, I have developed a new base Pool called ResourceLimitingPool.  This pool actually enables you do get the behavior of the HardResourceLimitingPool and SoftResourceLimitingPool in addition to new functionality.

Main Features of ResourceLimitingPool:
1) Soft and Hard pool limiting.

2) Allow configurable blocking on get() for unavailable resources. with a configurable timeout on the block.
	When the maximum size of the pool is fixed, that number of resources are outstanding and blocking is enabled, calls to get() will block until one or more resources are returned to the pool with a put().

3) Allow the pool to delete resources when they are no longer needed without hurting performance.
	If a trim interval is specified when creating the pool, the pool will attempt to trim unused objects from the pool.  Objects that were used within the interval will not be trimmed.  This was implemented in a way that should not hurt performance.


There is also an extension to the ResourceLimitingPool, called ValidatedResourceLimitingPool which adds a method for Validating objects before they are returned to the caller of get().  This is done without code duplication and in a way which allows for more than one object to be invalid without any errors.

Added a Validatable interface for objects that know how to validate themselves.

There are also several tests of the ResourceLimitingPool which should go in the tests directory.   (Yes, I actually wrote tests!)  They take advantage of the newest version of jUnitPerf.



New classes for the org.apache.avalon.excalibur.datasource package:

Added a new ConnectionPool called ResourceLimitingJdbcConnectionPool.  This version extends ValidatedResourceLimitingPool and knows how to validate connections in the pool.  Connections are only validated with a ping if they have not been used for more than 5 seconds.

Added a new implementation of a DataSource called ResourceLimitingJdbcDataSource.  This implementation uses a ResourceLimitingJdbcConnectionPool to take advantage of the new Blocking and Trimming features.



New classes for the org.apache.avalon.excalibur.thread.impl package:

Added a new ThreadPool implementation called ResourceLimitingThreadPool which will block for threads when unavailable and trim threads which are no longer needed.



If you wish, the pool and datasource classes could go in the main package or in the scratchpad.  The thread class should go with the other thread classes in the scratchpad.

Let me know if you have any questions about these implementations or their use.  They all have fairly good Javadocs telling how to use them.

Cheers,
Leif

Re: New ResourceLimiting Pool for Scratchpad

[Leif Mortenson <le...@silveregg.co.jp>]

Committed.

Leif Mortenson wrote:

>I have found that in many cases it was necessary to have a pool of resources which would have an upper limit on the size, like the HardResourceLimitingPool, but would not throw an exception when resources are not available.  The desired functionality was to block until the resource became available.  I found this to be most critical when dealing with JdbcConnectionPools and ThreadPools.
>
>
>
>New classes for the org.apache.avalon.excalibur.pool package:
>To solve this problem and others, I have developed a new base Pool called ResourceLimitingPool.  This pool actually enables you do get the behavior of the HardResourceLimitingPool and SoftResourceLimitingPool in addition to new functionality.
>
>Main Features of ResourceLimitingPool:
>1) Soft and Hard pool limiting.
>
>2) Allow configurable blocking on get() for unavailable resources. with a configurable timeout on the block.
>	When the maximum size of the pool is fixed, that number of resources are outstanding and blocking is enabled, calls to get() will block until one or more resources are returned to the pool with a put().
>
>3) Allow the pool to delete resources when they are no longer needed without hurting performance.
>	If a trim interval is specified when creating the pool, the pool will attempt to trim unused objects from the pool.  Objects that were used within the interval will not be trimmed.  This was implemented in a way that should not hurt performance.
>
>
>There is also an extension to the ResourceLimitingPool, called ValidatedResourceLimitingPool which adds a method for Validating objects before they are returned to the caller of get().  This is done without code duplication and in a way which allows for more than one object to be invalid without any errors.
>
>Added a Validatable interface for objects that know how to validate themselves.
>
>There are also several tests of the ResourceLimitingPool which should go in the tests directory.   (Yes, I actually wrote tests!)  They take advantage of the newest version of jUnitPerf.
>
>
>
>New classes for the org.apache.avalon.excalibur.datasource package:
>
>Added a new ConnectionPool called ResourceLimitingJdbcConnectionPool.  This version extends ValidatedResourceLimitingPool and knows how to validate connections in the pool.  Connections are only validated with a ping if they have not been used for more than 5 seconds.
>
>Added a new implementation of a DataSource called ResourceLimitingJdbcDataSource.  This implementation uses a ResourceLimitingJdbcConnectionPool to take advantage of the new Blocking and Trimming features.
>
>
>
>New classes for the org.apache.avalon.excalibur.thread.impl package:
>
>Added a new ThreadPool implementation called ResourceLimitingThreadPool which will block for threads when unavailable and trim threads which are no longer needed.
>
>
>
>If you wish, the pool and datasource classes could go in the main package or in the scratchpad.  The thread class should go with the other thread classes in the scratchpad.
>
>Let me know if you have any questions about these implementations or their use.  They all have fairly good Javadocs telling how to use them.
>
>Cheers,
>Leif
>



--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>