• Post Reply Bookmark Topic Watch Topic
  • New Topic

how to build cache mechanism  RSS feed

 
Meir Yan
Ranch Hand
Posts: 599
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hello all
i have application that basically loading very big object that contains sub objects and
doing dynamic lookup by name of the object and the method i like to invoke and then invoke it
everything done ofcorce with reflection .
now this application will be called handeret times per minute .
some questions .
first of all do i need caching mechanism? for saving the subobject that had bean called in some kind of vector in memory for example or if i use reflection , i dont need caching mechanism .
second question is do i need threads here ? if i do , how i buid some kind of locks to this threads ?

thanks
 
Stan James
(instanceof Sidekick)
Ranch Hand
Posts: 8791
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
The caching that you describe is a bet that using memory to hold things will be better than using CPU cycles to fetch or create them again and let them go into GC. So before you go any further, how do you know that the delays in reflection are a problem big enough to deserve your time and effort? Try it without caching, put some timing on it and prove it hurts before you fix it.

Caches are usually pretty simple singletons or static variables holding a map. Make up some kind of key for objects so you can tell if they're already there or not.

A level up from the cache is something that says

BTW: That's the method to make non-caching the first time around.

Caches get much trickier if the things you store can go bad or require a refresh. Doesn't sound like you'll have that problem unless you can reload classes.

I wouldn't worry about adding threads to handle this stuff, but if the app multi-threads at all you ought to make the cache and that method shown above thread safe.

Does that answer your questions or raise more?
[ September 14, 2006: Message edited by: Stan James ]
 
Meir Yan
Ranch Hand
Posts: 599
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hello and thanks for the fast reply as understand this implementation for simple cache mechanism
It looks like it will fit my case some things I didn�t understand:
"Caches get much trickier if the things you store can go bad or require a refresh. Doesn't sound like you'll have that problem unless you can reload classes"

What do you mean by "refresh" why do I need refresh? In what case? And why I need reload class?
Thanks
 
Stan James
(instanceof Sidekick)
Ranch Hand
Posts: 8791
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I was trying to think of a short phrase to cover all the ways something in a cache could go bad. If it's a connection, the other end might go down. If it's a simple value like current user's name, someone could log off and someone else log on. If it's a memory version of something that is persisted in a database, somebody else could update the database value. I'm sure there are many more. If there is any chance that the value in your cache could go stale you'll have to figure out what to do about it.

From your description, I think you don't have to worry about this. That would be a blessing.
 
Don't get me started about those stupid light bulbs.
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!