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