db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Anders Morken (JIRA)" <derby-...@db.apache.org>
Subject [jira] Updated: (DERBY-801) Allow parallel access to data files.
Date Wed, 24 May 2006 13:09:30 GMT
     [ http://issues.apache.org/jira/browse/DERBY-801?page=all ]

Anders Morken updated DERBY-801:
--------------------------------

    Attachment: NIO-RAFContainer-v1.patch

NIO-RAFContainer-v1.patch is an experimental patch using the java.nio (New IO) framework to
perform concurrent reads and writes to the same file without mutual exclusion. It passes storeall
for me with Sun Java 1.4.2_09 on Linux, but needs some cleanup and refinement - and I don't
even know if it actually helps performance yet. =)

> Allow parallel access to data files.
> ------------------------------------
>
>          Key: DERBY-801
>          URL: http://issues.apache.org/jira/browse/DERBY-801
>      Project: Derby
>         Type: Improvement

>   Components: Performance, Store
>     Versions: 10.0.2.0, 10.0.2.1, 10.1.1.0, 10.1.1.1, 10.1.1.2, 10.1.2.0, 10.1.2.1
>  Environment: Any
>     Reporter: Øystein Grøvlen
>  Attachments: NIO-RAFContainer-v1.patch
>
> Derby currently serializes accesses to a data file.  For example, the
> implementation of RAFContainer.readPage is as follows:
>     synchronized (this) {  // 'this' is a FileContainer, i.e. a file object
>         fileData.seek(pageOffset);  // fileData is a RandomAccessFile
>         fileData.readFully(pageData, 0, pageSize);
>     }
> I have experiemented with a patch where I have introduced several file
> descriptors (RandomAccessFile objects) per RAFContainer.  These are
> used for reading.  The principle is that when all readers are busy, a
> readPage request will create a new reader.  (There is a maximum number
> of readers.)  With this patch, throughput was improved by 50% on
> linux.  For more discussion on this, see
> http://www.nabble.com/Derby-I-O-issues-during-checkpointing-t473523.html
> The challenge with the suggested approach is to make a mechanism to
> limit the number of open file descpriptors.  Mike Matrigali has
> suggested to use the existing CacheManager infrastructure for this
> purpose.  For a discussion on that, see:
> http://www.nabble.com/new-uses-for-basic-services-cache---looking-for-advice-t756863.html

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