Win a copy of The Little Book of Impediments (e-book only) this week in the Agile and Other Processes forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

NX: No caching at all - is that OK?

 
Mogens Nidding
Ranch Hand
Posts: 77
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi all!
My current data access class is really slow and dumb: It doesn't cache anything, and every record access is effectuated through many small read/write operations. This may be especially noticable for the find operation.
Do you think I can justify my no-cache policy by simply saying that it gives great simplicity, and since the system will only support the CSRs, a heavy load is not expected?
It seems many people read the entire database into memory on startup. Is this a better approach? It is just as simple, if not simpler, and it will surely performs much, much, much, much better, at least on the small (and perhaps also realistic?) example databases that come with the assignments.
The only disadvantage is that I wouldn't expect it to work well with large databases.
 
Satish Avadhanam
Ranch Hand
Posts: 697
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Nicky, its OK I think.
Originally posted by Nicky Bodentien:
Hi all!
My current data access class is really slow and dumb: It doesn't cache anything, and every record access is effectuated through many small read/write operations. This may be especially noticable for the find operation.

Are you not searching the entire db at a time here i.e. open the file, read each record, compare it, add to resultSet, close the file? Or I think you should be doing something like this: read first record(using your read method which opens file and closes for each read operation), compare it, if matches add to resultSet...and so on for all records?
Both should be fine Nicky.

Do you think I can justify my no-cache policy by simply saying that it gives great simplicity, and since the system will only support the CSRs, a heavy load is not expected?

That's true. For the scope of assignment we can ignore the performance, security(except basic locking/sychronization) and loading issues.

It seems many people read the entire database into memory on startup. Is this a better approach? It is just as simple, if not simpler, and it will surely performs much, much, much, much better, at least on the small (and perhaps also realistic?) example databases that come with the assignments.
The only disadvantage is that I wouldn't expect it to work well with large databases.
You don't need to worry about the performance issues. Whatever you did, you can just document your assumptions and that should do.

Good Luck
 
George Marinkovich
Ranch Hand
Posts: 619
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Nicky,
I agree with Satish, there's no requirement for you to use a cache for the project. The design you describe sounds fine.
 
Mogens Nidding
Ranch Hand
Posts: 77
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks for both your replies - it makes me a lot easier!
Originally posted by Satish Avadhanam:
Are you not searching the entire db at a time here i.e. open the file, read each record, compare it, add to resultSet, close the file? Or I think you should be doing something like this: read first record(using your read method which opens file and closes for each read operation), compare it, if matches add to resultSet...and so on for all records?
Both should be fine Nicky.

I don't close the file until the finalize method is called (or perhaps I will require clients to call a close-ish method on the data access object). The justification is that it's simple (unless of course, the matter of making sure the file is closed turns out to be complicated).
 
Javini Javono
Ranch Hand
Posts: 286
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi,
In running George's super software exerciser, and watching the system monitor
on my Macintosh, even though I too write and read directly to a RandomAccessFile,
the operating system is smart enough to spend most of its time writing, and doing
very little reading (i.e., it already is buffering for you behind the scenes).
So, no need to get too fancy, and I agree with George. Either Sun's Java or the
operating system carries out that kind of optimization.
Thanks,
Javini Javono
[ March 10, 2004: Message edited by: Javini Javono ]
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic