Meaningless Drivel is fun!*
The moose likes Developer Certification (SCJD/OCMJD) and the fly likes how to flush the cache into flat file Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of The Java EE 7 Tutorial Volume 1 or Volume 2 this week in the Java EE forum
or jQuery UI in Action in the JavaScript forum!
JavaRanch » Java Forums » Certification » Developer Certification (SCJD/OCMJD)
Bookmark "how to flush the cache into flat file" Watch "how to flush the cache into flat file" New topic
Author

how to flush the cache into flat file

Roberto Leong
Greenhorn

Joined: Apr 14, 2004
Posts: 1
Hi

I have been assigned with URLyBird version 1.3.1

I have decided to implement the locking mechanism on record level with a mutex as provided in Doug Lea's book. All records are stored in memory in a cache.

For every update/delete/create in the cache these changes have to be reflected back to the flat file (in my case a RandomAccessFile). Does this means that I will have to have a locking mechanism on record level and one for the RAF (I only have one raf open for the duration of the application)?

How are people that use caching reflecting the changes back to the database file?

cheers
Roberto
K Madan
Greenhorn

Joined: Apr 08, 2004
Posts: 10
Hi
I am cashing the records (B&S) but I am not sure is it right approach as I am using an Arralist for cashing the the stuff thus limiting the number of records to an Integer Max ??
any body got other idea

thanks
T. Anthony Chen
Ranch Hand

Joined: Jul 28, 2004
Posts: 38
I have a concern in general about caching all the records in memory. It is based on the assumption that you have a big enough memory to hold all the records from the flat file. Is this a safe assumption to make in terms of the SCJD exam?


T. Anthony Chen<br />---------------<br />SCJP, SCJD, SCBCD, SCWCD, SCEA
K Madan
Greenhorn

Joined: Apr 08, 2004
Posts: 10
I agree Anthony, I think we should not cache the records from the flat file
how is everybody else doing ??

thanks
T. Anthony Chen
Ranch Hand

Joined: Jul 28, 2004
Posts: 38
Glad that you agree, KM.

But I am not so sure if you can't do this, actually. I am doing the B&S 2.11 assignment and one of the requirements states:

"It must allow the user to search the data for all records, or for records where the name and/or location fields exactly match values specified by the user. "

My interpretatin on "search the data for all records" is that you need to be able to bring all the records back and display them to the user, which implies that fitting all the records into memory is not a restriction.

Personally, I am not planning to cache all records in memory just for simplicity sake. For me, SCJD emphasizes simplicity over performance. But I may change my mind when I go deeper into my design.
Andrew Monkhouse
author and jackaroo
Marshal Commander

Joined: Mar 28, 2003
Posts: 11432
    
  85

Hi Roberto,

Welcome to JavaRanch and this forum.

For every update/delete/create in the cache these changes have to be reflected back to the flat file (in my case a RandomAccessFile). Does this means that I will have to have a locking mechanism on record level and one for the RAF (I only have one raf open for the duration of the application)?


If there is the potential for more than one thread to update your physical data file, then you will need to put the data file access methods into a synchronized block.

Regards, Andrew


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

Joined: Jul 02, 2004
Posts: 476
Originally posted by Roberto Leong:
Hi

I have been assigned with URLyBird version 1.3.1

I have decided to implement the locking mechanism on record level with a mutex as provided in Doug Lea's book. All records are stored in memory in a cache.

For every update/delete/create in the cache these changes have to be reflected back to the flat file (in my case a RandomAccessFile). Does this means that I will have to have a locking mechanism on record level and one for the RAF (I only have one raf open for the duration of the application)?

How are people that use caching reflecting the changes back to the database file?

cheers
Roberto


Hi, Roberto! I will implement something like this:



or something along those lines. That way I update the db file first, and only then I update the cache.


Anton Golovin (anton.golovin@gmail.com) SCJP, SCJD, SCBCD, SCWCD, OCEJWSD, SCEA/OCMJEA [JEE certs from Sun/Oracle]
Andrew Monkhouse
author and jackaroo
Marshal Commander

Joined: Mar 28, 2003
Posts: 11432
    
  85

Hi K Madan & T. Anthony Chen

Originally posted by K Madan:
I am cashing the records (B&S) but I am not sure is it right approach as I am using an Arralist for cashing the the stuff thus limiting the number of records to an Integer Max ??


I wouldn't worry to much about exceeding 2,147,483,647 records - you should find considerably less in the data file provided.

You may want to mention that this is a known limitation in your design decisions document though.

Originally posted by T. Anthony Chen
I have a concern in general about caching all the records in memory. It is based on the assumption that you have a big enough memory to hold all the records from the flat file. Is this a safe assumption to make in terms of the SCJD exam?


All the data files I have seen so far are under 10 Kb in size, so I don't think you should have too many concerns at this stage.

If you were worried about it, you could implement a SoftReference collection which would ensure that if memory ever became an issue then the JVM can reclaim the memory. You would presumably then add some logic to load from memory where possible, but reload from disk if not possible (even a lazy loading scheme?).

And - as mentioned to K Madan - you may want to put your concerns / ideas into your design decisions document, just so the examiner knows you have thought about the issues.

Regards, Andrew
 
 
subject: how to flush the cache into flat file