You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-dev@db.apache.org by "Anders Morken (JIRA)" <de...@db.apache.org> on 2006/08/24 22:16:40 UTC
[jira] Updated: (DERBY-801) Allow parallel access to data files.
[ http://issues.apache.org/jira/browse/DERBY-801?page=all ]
Anders Morken updated DERBY-801:
--------------------------------
Attachment: DERBY-801-v3.patch
DERBY-801-v3.patch is a cleaned up version of DERBY-801-v2.patch.
First off, thanks to Knut Anders for a thorough review - I appreciate it, even the
nitpicking. Part of my motivation for doing this is to get rid of my bad habits. =)
Now, about this patch - I'll just reply to KAH's comments in the order they appeared.
1) I didn't particularly feel like modifying the interfaces in this patch.
Incremental development, right? ;-) Maybe we should stick a note in JIRA about it.
The problem with the instanceof check is that RAFContainer4 will fall back to old
behavior on tests that utilize the functionTests/util/corruptio/CorruptRandomAccessFile
class to simulate a broken file, and thus it won't be tested there. May not really be an
issue now, but could be one in a similar case later. Maybe I'm just paranoid. =)
2) OK =)
3) Good point, fixed.
4) updatePageArray() was only called from within a synchronized block before, so I
didn't trust it to be MT-safe. To make the fast path lock-free I moved the synchronization
inside the if/else blocks. Could be removed if you're sure it's safe? =)
5-14) Thanks, fixed. =)
I've tried to make sure the code adheres to the Java Coding Conventions now. I made one
exception (hopefully for the better): after a method head/if condition has been broken into multiple
lines I've used a newline before the { to make it easier to spot where the method head ends and
the body starts. Should be quick to fix if you disagree with me, anyway. =)
> Allow parallel access to data files.
> ------------------------------------
>
> Key: DERBY-801
> URL: http://issues.apache.org/jira/browse/DERBY-801
> Project: Derby
> Issue Type: Improvement
> Components: Performance, Store
> Affects 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
> Assigned To: Anders Morken
> Attachments: DERBY-801-v2.patch, DERBY-801-v3.patch, 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