I have tested this on a sun jdk 1.4.2 and an ibm 1.42 on windows and I believe it has also been tested against a linux jdk 1.4.2.
Do you have any time to write a test case of the I/O calls separate from derby? This has the feel of a JVM bug, but maybe the interfaces are not being used correctly. This is a relatively new feature in jvm's (and new code in derby) so could be a bug in either area.
It would be nice if a work around can be found to get this up and running in the OSX environment but not have to pay the extra performance cost across all the other JVM's.
Joseph Grace wrote:
Dear Suresh:
Thank you for your informative reply and explanations of the original code. Much appreciated. I am relearning java and learning derby as I go here, so I'll answer your questions as I can. Add salt to taste as most of my "knowledge" I gleaned from the comments in the code I modified.
FYI, I am using the most up-to-date OSX 10.3.5 and ditto for OSX java:
java version "1.4.2_05" Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_05-141) Java HotSpot(TM) Client VM (build 1.4.2-38, mixed mode)
and I have not tested on any other platform.
I believe your assessments below are correct.
Suresh Thalamati wrote:
I am trying to understand the problem you described above. What is the error you are seeing when you try to create the database in the Mac environment. Are u seeing this problem with JDK1.4.2 on any other OS ? Could you please explain more on how database can be created twice ? From the changes described here, what I find is you are trying to avoid open/create of log file in "rw" mode first and then in "rws" mode by making it a single privRandomAccess File call:
>> StorageRandomAccessFile theLog = privRandomAccessFile( logFile, isWriteSynced? "rws": "rw");
Yes, I merged the file creations to get the code working (and avoid a "File exists" exception:
~/derby$ java -cp jars/sane/derby.jar:jars/sane/derbytools.jar org.apache.derby.tools.ij
ij version 10.0 (C) Copyright IBM Corp. 1997, 2004.
ij> connect 'jdbc:derby:test;create=true';
ERROR XJ041: Failed to create database 'test', see the next exception for details.
ERROR XBM01: Startup failed due to an exception, see next exception for details.
ERROR XJ001: Java exception: '/Users/occam/dev/java/derby/test/log/log1.dat (File exists): java.io.FileNotFoundException'.
ij>
I thought there may have been some rush changes in the handoff from IBM to Apache which left a bug overlooked in java 1.4.2 (mea culpa). I did not realize the double-open was intended as an optimization (since it fails on my system and so seemed a bug).
The error is a little misleading but, looking under the covers, I was able to confirm the existence of "log1.dat" (or somesuch) at the time of the error report attempt to recreate/open "log1.dat". So, "File exists" is the correct complaint. I have no idea whether that's in/correct behavior. If there is incorrect behavior on OSX's java 1.4.2_05, please describe it, and I shall submit it to Apple (or you can, as desired).
I think the following part of the changes might increase database creation time when write sync is enabled..
Aha. Yes, it does take quite a long time now that you mention it. I'm glad that may not be normal.
Please correct me if my observation is not right . I think the Reason behind opening files in "RW" mode first and then reopen in "RWS" might have been to make preallocation of the log file finish faster. . Preallocation of the log file by doing writes to a file opened in "rws" mode will be much slower than doing writes to file opened in "rw" mode .
Sounds good to me (i.e., I'll take your word for it :-).
Apologies for any confusion. Please let me know whether this fixes a bug or not, or whether I should submit a bug report to Apple for OSX java instead?
Thanks,
= Joe =
