aspose file tools*
The moose likes Developer Certification (SCJD/OCMJD) and the fly likes B&S: Opening database Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Certification » Developer Certification (SCJD/OCMJD)
Bookmark "B&S: Opening database" Watch "B&S: Opening database" New topic
Author

B&S: Opening database

Derek Canaan
Ranch Hand

Joined: Nov 05, 2003
Posts: 64
Hi,
Please comment:

Q1: Is mode "rw" ok? Some use "rwd"? Any advantage?
Q2: If i plan to open raf only when file is updated, is the end of constructor the right place to close the raf as code above? Reading from file only happens once at cache = populateCache() in constructor during the first instantiation of Data (singleton). All future reads are done via the cache.
Q2b: Does raf need to be set to null after raf.close()
Q3: Is the writeRecordToFile ok? Instantiating raf again at the beginning and closing it and setting to null when finish.
Thanks in advance,
Derek
Jay Bromley
Ranch Hand

Joined: Aug 09, 2003
Posts: 48
Derek,
Your constructor and writeRecordToFile look fairly reasonable. One thing you may want to do is put your file access in a try...finally block with the close and setting to null in the finally block. This way if there is an exception while reading the file, then the file still gets closed. The same thing goes for the writeRecordToFile. Now, for the questions

Is mode "rw" ok? Some use "rwd"? Any advantage?

I think you should be ok here, but note that in the constructor no writing is done, you check the magic cookie, perhaps read in some record metadata and that's about it, so really the mode "r" should be enough.
For the writeRecordToFile method, you may want to use "rwd". This just means that whenever you write to the file, the buffer is immediately flushed, so things immediately get to disk. One might argue that this could prevent data loss in some catastrophic event since data won't wait around until some output buffer is filled, but since you're opening the file, updating it and then closing immediately, I don't there's much benefit to "rwd". I'm not sure what the down side might be.

Q2: If i plan to open raf only when file is updated, is the end of constructor the right place to close the raf as code above?

I think this is fine. At least I hope so, because this is how I did it.

Q2b: Does raf need to be set to null after raf.close()

In your case, yes. This way your sure the RandomAccessFile can be garbage collected. I assume the File object f is a class member, though your code doesn't mention it. In my code I made the RandomAccessFile a method local variable in methods that actually read and write the file in an effort to keep only essential stuff in the class. The File is a class member, since I assume one database file is used for any given run of the database (users have to exit and restart the app to change the database file.)

Q3: Is the writeRecordToFile ok? Instantiating raf again at the beginning and closing it and setting to null when finish.

Again, I think this is ok (adding the try...finally... as mentioned above, and this is similar to how I've done it.
Regards,
Jay
Andrew Monkhouse
author and jackaroo
Marshal Commander

Joined: Mar 28, 2003
Posts: 11486
    
  94

Hi Derek,
You have implied that you want your Data class to be a Singleton, but your implementation has a public constructor. Therefore it is not a Singleton. Personally I think it is better to leave it open like this - that way you could instantiate another instance of Data class for another database table if you needed to. But I would not go calling it a Singleton in your design documentation
If you follow Jay's advice that you open the file in read only mode during your load of the cache, then you will probably find that you no longer need a global RandomAccessFile variable.
Regards, Andrew


The Sun Certified Java Developer Exam with J2SE 5: paper version from Amazon, PDF from Apress, Online reference: Books 24x7 Personal blog
Derek Canaan
Ranch Hand

Joined: Nov 05, 2003
Posts: 64
Hi,
Jay, thanks for your very thorough and helpful comments.
[Jay]:Your constructor and writeRecordToFile look fairly reasonable. One thing you may want to do is put your file access in a try...finally block with the close and setting to null in the finally block. This way if there is an exception while reading the file, then the file still gets closed.

Did you mean this:

1. finally block to close raf and make it eligible for gc.
2. No catch block because any IOException will be handled by method who instantantiates the Data instance. Is this ok?

[Andrew]:You have implied that you want your Data class to be a Singleton, but your implementation has a public constructor. Therefore it is not a Singleton. Personally I think it is better to leave it open like this - that way you could instantiate another instance of Data class for another database table if you needed to. But I would not go calling it a Singleton in your design documentation

As it is, Data is not a Singleton. I'm transiting these codes to networked mode, hence i'm now considering thread-safe db, synch issues, and suitable architectural design for networked mode which may include a Singleton Data.
Please comment on this draft design, anyone.
updateRecord
------------

Q1: Comments on method, anyone?
Thread-safety design
--------------------
1. Cache is populated when the first Data object is instantiated.
2. The cache object is used as a mutex for read, update, delete, create, lock and unlock (like update method above):

3. The find method has *NO* synchronization on the mutex. It uses the read method which sync on the mutex. I allow dirty reads, and stale records to be presented on gui.
4. The only time where the db file is read is during the first instantiation of Data (in populateCache()). All future reads are done via the cache.
5. The db file is written on during update, delete, create, all of which sync on the mutex. This forces only one method at a time to set the file pointer and do its write operation. Hence i do not need to synch on the raf directly to ensure file position integrity during concurrent read and write.
6. File access (read and write) is done via a local variable raf.
7. All writeToFile is done only after the cache mutex is attained.
Q2. Is design thread-safe?
Q3. Any comments on design?
Q4. Have i got all my bases covered? Any possibility of deadlock, race condition, etc? Any holes?
Q5. One reason why i lean towards Singleton Data is my worry on tester invoking:

Would design fail this test and causes db.db file to be corrupted if Data is not a Singleton? Singleton Data would force d2 to have same reference/instance as d1.
thanks in advance,
derek
Jay Bromley
Ranch Hand

Joined: Aug 09, 2003
Posts: 48
Derek,
Your code:

is exactly what I mean. It's a good strategy for clean-up when there is a possibility for exceptions that cannot be handled inside the method. This might also come in handly, for example, when dealing with locking/updating/unlocking records:

Note that I assume that the methods called throw one of the declared exceptions and that the above is the basic skeleton, you may want to do some verification on the Contractor and catch exceptions thrown by unlock.
Regards,
jb
[ January 12, 2004: Message edited by: Jay Bromley ]
Derek Canaan
Ranch Hand

Joined: Nov 05, 2003
Posts: 64
Hi Jay,
Thanks again. With regard to the clean up in the book method, that is what i will do to release the lock in the event of exception being thrown during the lock/re-read/update/unlock sequence. I have a query on exception handling in book() method in adapter (seeB&S: Exception handling in book method in adapter )
Would really appreciate your comments on that strategy.
Thanks,
Derek
Derek Canaan
Ranch Hand

Joined: Nov 05, 2003
Posts: 64
Hi,
I have re-post my questions on updateRecord and thread-safe on a separate thread because they are separate from this topic. Please go to B&S: updateRecord & thread-safe design for comments and discussion on this topic.
thanks,
derek
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: B&S: Opening database