Memory cache for file contents, is the right way to go ?

[Guvenc Gulce]

Hi All,

I am currently implementing my Data class (B&S) and I would like to have
some ideas from you guys regarding my approach..

-> My Data class is a singleton and has a static RAF and a static Record List (which gets opened in the constructor)

-> In the constructor of data class I read the whole file contents to memory(Record List) and do all the job in memory.(Search, Update, Read)

-> I am not sure when to flush memory contents(Record List) to the file. One idea would be to touch also the file together with memory during update,create,delete ???

-> I have created a class called GenericColumn (which has length(in bytes) and name of each available column from file's metadata information)

-> and I also have a Contractor class which get's an array of GenericColumn as a parameter in its constructor. (so it will have an idea about the column names and lengths) so I try not to hardcode any column info. In case a new column gets added to metadata. It will do the job without any change.

What you guys think about this approach ? do you see any obvious flaws in the design ? and also when to flush memory to the file ? (not using nio memory mapper and doing it by myself would be a good idea? as it says I should always use available APIs from the Java 2 but memorymapper is platform specific maybe I can justify my choice

Thanks for your inputs

Guvenc Gulce

[Hanna Habashy]

hi Guvenc:
Storing the database in the memory will give advantage in performace, no doubt. How about if the database file is larg. How can you store it in memory?? Lets say the database file is 150 MB, and the heap size is 128 MB, can you predict what will happen?

[Jon Entwistle]

Hi Guvenc,

My opinion (no guarantees given ;-)):

-> My Data class is a singleton and has a static RAF and a static Record List (which gets opened in the constructor)

I would be very wary of using a singleton unless you have a very good justification for it (remember that you need to code thinking about future enhancements to the app - if you want to add another table, a singleton will be a hinderance). A reasonable way to go would be to allow have a data access class for each table (that may be added in the future).

-> In the constructor of data class I read the whole file contents to memory(Record List) and do all the job in memory.(Search, Update, Read)

A reasonable way to go - I wouldn't worry about the memory limitations (although I would mention it in the choices.txt). You would need a silly amount of records to trip an out of memory error - and sincerely, if you need that many records, you don't use a file based db ;-)

-> I am not sure when to flush memory contents(Record List) to the file. One idea would be to touch also the file together with memory during update,create,delete ???

I would ensure that you mirror any update to the cache immediately from within a synchronized block and leave it at that. There is no need to touch the files.

-> I have created a class called GenericColumn (which has length(in bytes) and name of each available column from file's metadata information)

I'd call it MetaData ;-) - Xounds like the job for an inner class.

-> and I also have a Contractor class which get's an array of GenericColumn as a parameter in its constructor. (so it will have an idea about the column names and lengths) so I try not to hardcode any column info. In case a new column gets added to metadata. It will do the job without any change.

not using nio memory mapper and doing it by myself would be a good idea?

IMHO the 'ready made' raf methods are ideal for the job in hand and reduce complexity wrt the NIO.


Good luck!