[
https://issues.apache.org/jira/browse/DERBY-2086?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rick Hillegas closed DERBY-2086.
--------------------------------
Resolution: Won't Fix
The interested engineer seems to have moved on, so I am closing this issue. It
can always be re-opened if someone wants to contribute more.
> 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: 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.
-
You can reply to this email to add a comment to the issue online.
