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

To cache or not to cache.

 
Anton Golovin
Ranch Hand
Posts: 527
1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I realize this question may be a little bit into the realm of design decisions and thus everyone may solve it differently. However, what would you recommend: to cache records, even though it is impractical, for the purposes of this assignemnt; to cache only part of records (i.e., index and deleted record numbers), or not to cache at all.

My design involves complete caching of records even though it is impractical: but find is fast.

Please share your decisions, as well, if you will. I think this is one of the central design decisions, and I was just wondering the take on it from other people.
 
Udham Singh
Greenhorn
Posts: 13
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I think implementing caching is very unnecissary. It is a complex problem in its own right. I would love to know what your replacement (paging) policy is But even the simplest solution is way beyond the requirements for this project.

The db file given to us is extremely small. We dont provide anything in the GUI to let the DB to grow either. If the client expects the DB to grow considerably he should probably try to get an actual Database.

For the file given to us the OS is probably going to cache it to some extent I really wouldn't bother caching it again.

But again. I would love to listen to some of the arguments in favour of a caching mechanism in our code.

Please let me know what you have in mind. Maybe I am missing something.
 
Vinay Selvaraj
Greenhorn
Posts: 6
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Finding records quickly is not a project requirement. Dont waste your time on it. The graders wont care if it takes 1 second to find a record within their test database of ~20 or if it takes 100 milliseconds.

The graders wouldn't want to spend too much time trying to understand how your application works. Keep them happy by making your app small and simple. Dont do anything more than you have to.

Good luck!
 
Andy Zhu
Ranch Hand
Posts: 145
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Yes, have seen a lot on this topic. Indeed, there is no hard rule to dictate which way one may go. There are some considerations for my choice: as part of a learning process, I prefer to use cache. I think in a real database application, the technique to solve the conflict of performance and storage is paging. However, in our simplified version, we are not required to implement this subsystem. so we are left these two choices (conceptually). To me, caching mimics paging, while we don't need to implement the complicated paging subsystem. This is one of my reasons.

Furthermore, we may not need to worry practical limits of memory. we can put this limitation in our doc. At least, sun doesn't say a hard word about this issue.
 
Paul Bourdeaux
Ranch Hand
Posts: 783
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
There has been a lot of discussion about caching in this forum in the past. Basically the general consensus is you will do just fine on the assignment whether you cache or not... as long as you document your design decision.

A cache will certainately improve preformance, and assuming you didn't go over the deep end when designing your data instance class, memory shouldn't be a problem (but is worth documenting). It does add some complexity to the code... but not that much (let's face it, a cache is a pretty simple instrument to implement).
 
Clivant Yeo
Ranch Hand
Posts: 124
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
For my case, I implement record caching using SoftReferences. Then I state an assumption that the company will use a commercial database when the size of database file gets too large. I feel that the codes for caching is easier to understand than codes that don't do caching. After all, the specs states that the codes had to be clear and simple to be understood by the junior programmers rite?

Furthermore, if the records are cached as objects, it will be easier to do locking. The record objects can be used as monitors for threading.

Just my 2 cents of opinion

Rgds,
Clivant
[ September 08, 2004: Message edited by: Clivant Yeo ]
 
Marlene Miller
Ranch Hand
Posts: 1392
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
about updating the cache
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic