Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Message-ID: <13520410.117641271866431852.JavaMail.jira@thor>
Date: Wed, 21 Apr 2010 12:13:51 -0400 (EDT)
From: "Rick Hillegas (JIRA)" <jira@apache.org>
To: derby-dev@db.apache.org
Subject: [jira] Closed: (DERBY-2086) Build a resource pooling subsystem to
 facilitate object reuse and concurrency
In-Reply-To: <6602631.1163585797269.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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