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)" <ji...@apache.org> on 2006/11/01 22:25:18 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-v5.patch
I'm attaching a patch (DERBY-801-v5.patch (relative to trunk), which incorporates Suresh's suggestion that I use the built-in Monitor mechanisms to boot an appropriate version of the BaseDataFileFactory. This removed a bunch of useless code, and should fix the "Caught exception when setting up rafContainerConstructor" errors. =)
M java/engine/org/apache/derby/modules.properties
M java/engine/org/apache/derby/impl/store/raw/data/BaseDataFileFactory.java
A java/engine/org/apache/derby/impl/store/raw/data/BaseDataFileFactoryJ4.java
D java/engine/org/apache/derby/impl/store/raw/data/RAFContainerFactory.java
M java/engine/org/apache/derby/impl/store/build.xml
$ diffstat DERBY-801-v5.patch
impl/store/build.xml | 2
impl/store/raw/data/BaseDataFileFactory.java | 29 +++---
impl/store/raw/data/BaseDataFileFactoryJ4.java | 47 ++++++++++
impl/store/raw/data/RAFContainerFactory.java | 110 -------------------------
modules.properties | 8 +
5 files changed, 73 insertions(+), 123 deletions(-)
derbyall passed without errors - it just took me a loong while to actually get around to running derbyall on this one. =)
I've also played with the LobLengthTest.junit test and provoked the error message, and what I've seen is that the problem happens when the container is being closed and deleted - the very same race condition case Knut Anders pointed out in previous comments. This happens when one thread starts closing the container just after a write has almost finished - after the write call to the FileChannel but before iosInProgress is decremented. So, it seems mostly harmless. Maybe moving the committedDropState check to the start of writePage and skipping the write altogether if it is in that state is a good approach? Any insight would be appreciated. =)
> 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.2.1
> Environment: Any
> Reporter: Øystein Grøvlen
> Assigned To: Anders Morken
> Attachments: DERBY-801-v2.patch, DERBY-801-v3.patch, DERBY-801-v4.patch, DERBY-801-v5.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