db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rick Hillegas (JIRA)" <j...@apache.org>
Subject [jira] Closed: (DERBY-2086) Build a resource pooling subsystem to facilitate object reuse and concurrency
Date Wed, 21 Apr 2010 16:13:51 GMT

     [ 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
> 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.

View raw message