[
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 file
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: 10.3.3.0, 10.4.1.3
> 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/[EMAIL
> PROTECTED],
> 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.
