db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Anders Morken (JIRA)" <j...@apache.org>
Subject [jira] Created: (DERBY-2086) Build a resource pooling subsystem to facilitate object reuse and concurrency
Date Wed, 15 Nov 2006 10:16:37 GMT
Build a resource pooling subsystem to facilitate object reuse and concurrency
-----------------------------------------------------------------------------

                 Key: DERBY-2086
                 URL: http://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: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Mime
View raw message