Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Message-ID: <18550365.1156586963455.JavaMail.jira@brutus>
Date: Sat, 26 Aug 2006 03:09:23 -0700 (PDT)
From: "Knut Anders Hatlen (JIRA)" <derby-dev@db.apache.org>
To: derby-dev@db.apache.org
Subject: [jira] Commented: (DERBY-801) Allow parallel access to data files.
In-Reply-To: <379656011.1136803530096.JavaMail.jira@ajax.apache.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

    [ http://issues.apache.org/jira/browse/DERBY-801?page=3Dcomments#action=
_12430721 ]=20
           =20
Knut Anders Hatlen commented on DERBY-801:
------------------------------------------

Thanks for addressing my comments, Anders. I see your point about
CorruptRandomAccessFile, but that is a test issue which could be
addressed later.

I still think it would be safe to use the old, unsynchronized
updatePageArray(). It is true that it is called from within a
synchronized block in RAFContainer.writePage(), but it is also called
with no synchronization in RAFContainer.privBackupContainer(). If you
look at privBackupContainer(), you'll see that the page is latched
before the call to updatePageArray(), and I think it is safe to assume
that the page is latched before a call to readPage() or writePage() as
well.

One more question: Is it possible that the container enters the
committed drop state while RAFContainer4.writePage() is executing? If
yes, what are the consequences?

I haven't figured out yet why the original code checks the value
returned by getCommittedDropState() in writePage(), but only has an
assert in readPage().

> 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: =C3=98ystein Gr=C3=B8vlen
>         Assigned To: Anders Morken
>         Attachments: DERBY-801-v2.patch, DERBY-801-v3.patch, NIO-RAFConta=
iner-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 obje=
ct
>         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-adv=
ice-t756863.html

--=20
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: htt=
p://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira