db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Suresh Thalamati <tsur...@Source-Zone.org>
Subject Re: java1.4.2 "rws" mode fix: LogToFile.java diff
Date Sat, 04 Sep 2004 01:06:05 GMT

Tested this case with a simple  Java program that opens a  file in "rw" 
mode first and then reopens in "rws":  mode similar to the
calls derby logging system makes. It also failed  with the similar error 
on  latest jdk142 (build 1.4.2_05-1) from Apple:
Exception in thread "main" Java.io.FileNotFoundException: log.dat (File 

Test program works fine on Win2k with jdk142. I  think this is bug in  
latest jdk142 from Apple.  Work around for this problem is disabling the 
write sync mechanism for transaction log. Write sync mode can be 
disables by setting  "derby.storage.fileSyncTransactionLog=true" in 
derby.properties. When this property is set  to true  logging system 
does  file syncs on commits  similar to what happens on jvms before jdk142.

Insert/deletes/updated ..etc can also fail on databases that were 
created with earlier jvm's  when
booted with the latest jvm because log switch also make similar I/O 
calls.   If  write sync mode is disabled on these
database, they  will work fine.  

Write Sync Test Java Program:

import java.io.*;

 * Test  synchronous writes on MAC with JDK1.4.2(updated 1).

public class TestWriteSync {
    public static void main(String [] args) throws Exception {
    RandomAccessFile raf;

    File file = new File("log.dat");
    if (file.exists())
    byte[] data = new byte[4096]; ;
    // open the file in rw mode
    raf = new RandomAccessFile(file,"rw");   
    //just write some bytes
    // reopen the above file in write sync mode
    // Note: following call is failing on MAC
    raf = new RandomAccessFile(file,"rws");
    //just write some bytes
    System.out.println("RWS MODE IS  WORKING FINE");


Mike Matrigali wrote:

> Joe I don't have access to an OSX 10.3.5. This error is strange, from 
> my reading of the java interfaces and the code the first call is 
> creating the file, and the second call should just be opening the 
> existing file -  and should not be getting a file exists error.
> 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 4(build 1.4.2_05-11)
>> 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 =

View raw message