db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Knut Anders Hatlen (JIRA)" <j...@apache.org>
Subject [jira] Updated: (DERBY-3726) Don't call RAFContainer.padFile() from instances of RAFContainer4
Date Wed, 18 Jun 2008 11:44:45 GMT

     [ https://issues.apache.org/jira/browse/DERBY-3726?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel

Knut Anders Hatlen updated DERBY-3726:

    Attachment: d3726-1a.diff

padFile() is called from three locations in RAFContainer. Two of the calls come from writePage(),
which is overloaded in RAFContainer4 and therefore not called by RAFContainer4. The last one
is in writeRAFHeader() where it is called if the container is being created.

This last call is the one we'll need to get rid of for RAFContainer4, and it is actually quite
easy to get rid of it for RAFContainer as well. Here's what writeRAFHeader() does when it's
called with create=true:

a) get an empty embryonic page by calling getEmbryonicPage(null), which is the same as calling
new byte[AllocPage.MAX_BORROWED_SPACE].

b) pass the empty embryonic page to writeHeader() which initializes it and writes it to the

c) call padFile() to make sure the file ends on a page boundary (to work around a bug in the
EPOC jvm)

Now, if the the byte array returned from getEmbryonicPage(null) had the size of a full page
instead of just a fraction of a page, the call to writeHeader() would automatically give us
a file that ended on a page boundary. The attached patch (d3726-1a) therefore replaces the
call to getEmbryonicPage(null) with new byte[pageSize], and then it can also remove the call
to padFile() and the special handling of fileData==null in getEmbryonicPage().

Derbyall and suites.All ran cleanly on Solaris 10/JDK 6.

> Don't call RAFContainer.padFile() from instances of RAFContainer4
> -----------------------------------------------------------------
>                 Key: DERBY-3726
>                 URL: https://issues.apache.org/jira/browse/DERBY-3726
>             Project: Derby
>          Issue Type: Improvement
>          Components: Store
>    Affects Versions:,
>            Reporter: Knut Anders Hatlen
>            Assignee: Knut Anders Hatlen
>            Priority: Minor
>         Attachments: d3726-1a.diff
> In this thread on derby-dev, http://mail-archives.apache.org/mod_mbox/db-derby-dev/200806.mbox/%3c48530848.3020501@sbcglobal.net%3e,
> it was mentioned that RAFContainer4 calls padFile() when creating a container. Since
padFile() uses old I/O calls and the rest of RAFContainer4 uses NIO, it could possibly cause
similar issues as those seen in DERBY-3347. Although we haven't verified that this is a problem,
we should try to avoid mixing old I/O and NIO to be on the safe side.

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message