[
https://issues.apache.org/jira/browse/DERBY-2086?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12462435
]
Anders Morken commented on DERBY-2086:
--------------------------------------
I just noticed that the Apache Jakarta project already has a generic object
pool package: http://jakarta.apache.org/commons/pool/
As the Jakarta Commons packages were made to be reused, and are released under
the ASL, I believe it makes sense to reuse such components in Derby.
> Build a resource pooling subsystem to facilitate object reuse and concurrency
> -----------------------------------------------------------------------------
>
> Key: DERBY-2086
> URL: https://issues.apache.org/jira/browse/DERBY-2086
> Project: Derby
> Issue Type: Improvement
> Components: Performance, Services
> Reporter: Anders Morken
> Priority: Minor
>
> It could be useful to have a somewhat generic internal resource pooling
> service.
> The objective of this service would be to provide other services with the
> facility to:
> 1) Reuse objects that are expensive to create and/or garbage collect
> 2) Provide enough of the resource to permit multiple independent threads to
> work without waiting for a single shared resource.
> 3) Limit resource allocation to avoid excessive memory usage - perhaps
> responding to heap memory pressure and available resources.
> ...without having to reimplement all the logic and data structures needed to
> take care of sizing the pool, enable fast retrieval and freeing of resources.
> The motivation for logging this issue is a desire to manage the encryption
> buffers used by the RAFContainer4 implementation in DERBY-801. Currently it
> allocates a page-sized buffer for each write that requires encryption, uses
> it once and forgets it. It is a byte array, inexpensive to allocate and
> garbage collect, but but its size and frequent allocation could cause rapid
> exhaustion of the allocation areas causing more frequent garbage collection.
> The original idea for DERBY-801 was to use a pool of file descriptors on the
> same file to permit concurrent IO to one file, but this work stopped, lacking
> a good way to manage that pool.
> This leads me to believe that if we could make a reasonably lightweight,
> simple, efficient and sufficiently generic resource pool manager, it could be
> useful in more scenarios than just the store subsystem. However, good,
> lightweight, efficient, generic resource management is difficult...
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
