• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Tim Cooke
  • paul wheaton
  • Liutauras Vilda
  • Ron McLeod
Sheriffs:
  • Jeanne Boyarsky
  • Devaka Cooray
  • Paul Clapham
Saloon Keepers:
  • Scott Selikoff
  • Tim Holloway
  • Piet Souris
  • Mikalai Zaikin
  • Frits Walraven
Bartenders:
  • Stephan van Hulst
  • Carey Brown

Writing updated database to file??

 
Ranch Hand
Posts: 146
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi,
I'm curious if anyone here has decided to write their database contents to file when the database is being closed. Is this necessary? I looked through the instructions from sun and it doesnt say anything specifically about writing the database back to file once you read it in. I would assume in a good design that changes to the database are written to the flat file and stored till the next execution of the database.
I tested writing my database's contents to a temp file using RandomAccessFile's writeXXXX methods, but it always comes out looking a little different then the original .db file I got from sun. Maybe im just using the wrong class to write with. I assumed that writing with RandomAccessFile would be the say as reading with it, but im getting a few more characters in between all of the writes that the original .db file doesnt have.
Any thoughts?
Thanks,
Dave
 
Ranch Hand
Posts: 47
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Dave,

I'm curious if anyone here has decided to write their database contents to file when the database is being closed.


IMO, it should be written to the file. To my understanding, SUN just view this flat file as the database. Thus, I did it.

I tested writing my database's contents to a temp file using RandomAccessFile's writeXXXX methods,


The file is store on the disk as bytes. So, I guess you like to make sure this presentation before writting it to the file. Hope this helps.
Rick
 
Dave Knipp
Ranch Hand
Posts: 146
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Rick,

The file is store on the disk as bytes. So, I guess you like to make sure this presentation before writting it to the file.


I don't know if i understand what you are saying. Do you mean i should be sure of this representation (as bytes) before writing to file?
I know that the file is stored on disk, in the file, as bytes. Its also written using a DataInputStream and DataOutputStream according to sun. So i would assume they wrote it using the writeInt(), writeShort(), etc. methods.
So i went ahead and tried that and the contents of my update db file is similar, but different than the file sun supplied. I was just curious if anyone had encountered this.
Didn't you just use a DataOutputStream to write the contents of your database to file?
Dave
 
Wanderer
Posts: 18671
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I looked through the instructions from sun and it doesnt say anything specifically about writing the database back to file once you read it in.
Dunno about your instructions, but mine said the following, under the "User Interface" section:

It must allow the user to book a selected record, updating the database file accordingly.


I'd imagine most assignments are similar in this respect. The question is though - when do you write to the file? The two major possibilities are (a) once when you close the DB, or (b) every single time a change is made. If you're using a DataOutputStream, the latter may sound unreasonable - why rewrite the entire DB file contents every time a change is made? But if you look at using a RandomAccessFile or FileChannel instead, you can usually write just the changed record to the approriate part of the file. You don't need to touch the majority of the file. In this case, option (b) is much more reasonable. And you don't have to worry so much about what happens if the server dies without a proper shutdown, because the file contents will still reflect the most up-to-date version of the data.
Well, if the server dies there are still strange things that could happen, and you aren't really expected to worry about all these possibilities for this assignment. But the point is, writing the changed records as they occur will significantly reduce the risk of these problems.
Note that RandomAccessFile has many of the same methods that you're using in the DataOutputStream. (Check out the DataOutput interface which defines these.) The different is, RAF allows you to seek() a particular position of the file before you start writing.
It's definitely possible to write your records correctly using various writeXXX() methods of RAF. However you need to be careful and read just what each of the method you use really does. In particular, for reading and writing Strings, neither writeChars() nor writeUTF() matched the required file format. Not exactly. Read the API carefully to see why. Consider using the methods that read and write a byte[] array instead, and figure out how to convert between a byte[] and a String. (The String class has all the methods you need.)
It's also possible to do all this with a FileChannel reading and writing a ByteBuffer. If that makes sense to you, go for it. But it's probably easier to use the RAF methods, so I'd work on that first.
 
Dave Knipp
Ranch Hand
Posts: 146
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Jim,
Thank you for your suggestions. I now have the db file updating after every record update through the RAF and String methods. I am using RAF in "rwd" mode which the API says should synchronously update the underlying storage device (the file).
My problem is that i just ran a mock 'crash' test on the server. (I killed the java process). Before i crashed it i made a change to a record to see if that change would be reflected in the file. Something odd happened, i had booked a record and unbooked it prior to my crash. It aws previously booked with the id '12345678' and when i crashed the server the file showed '2345678' instead. It seems like it was in the middle of writing the record to the file, but shouldnt that happen right after i write the updated Record as bytes to the RAF? It seems like it is waiting to write to the file until the server is closing... This is interesting, I will investigate, but if you have any ideas feel free
Thanks,
Dave
 
Jim Yingst
Wanderer
Posts: 18671
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Dave - interesting. Are you certain that (a) the proper value really was 12345678 (perhaps you mistyped this once?), (b) the system normally is able to write 12345678 correctly, and (c) you crashed the process after a suitable delay that should have given the server ample time to update the file? Really, a few seconds should be more than enough for the last, in most cases. Unless you were in the midst of a stress test and the server was busy handling lots of other things too. At some level, if you kill a process while it's running, you always have the possibility of cutting off the server mid-write. But if you're sure you provided enough time for the server to do whatever it was doing - I dunno. I can't think of any goood reason an RAF in rwd mode shouldn't be able to update such a short bit of data promptly.
If you're concerned with this sort of thing you may be better off using a FileChannel, as that class seems to offer more robust guarntees about its behavior than RAF does. Though here too, there are some annoying omissions in the guarantees, IMO. See here for more than you ever wanted to know about it.
 
Dave Knipp
Ranch Hand
Posts: 146
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Jim,
Ok i'll take a look at that, thanks for your help, I really appreciate it.
Dave
 
Seriously Rick? Seriously? You might as well just read this tiny ad:
Smokeless wood heat with a rocket mass heater
https://woodheat.net
reply
    Bookmark Topic Watch Topic
  • New Topic