Win a copy of Kotlin in Action this week in the Kotlin forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic

Cache in EJB tier  RSS feed

 
Jan Van Reusel
Greenhorn
Posts: 3
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi,
I want to build a cache in the business logic tier (POJO's and EJB's) for data that is used frequently but almost never updated. Example: postal codes, languages, professions, ... The application runs in a clustered environment. What is the best way to implement the cache and the propagation of updates?
For the cache, I am thinking of 3 alternatives:
- A singleton with a read/write lock. BUT: synchronization is not allowed according to the specs
- A stateless session bean. BUT: how to update all instances in the pool?
- Store all data in JNDI. BUT: performance issue
For the notification: JMS
Any ideas? Thanks,
Jan
 
Ajith Kallambella
Sheriff
Posts: 5782
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I have used a Singleton to implement a cache with lazy loading. Instead of synchronizing the read/write methods I have used a sychronizedMap to store the values. My implementation is actually a cache of cache. The DictionaryObject are read-only objects and the singleton CacheManager stores a cache of such objects.
To handle updates I simply register certain types of DictionaryObject( identified by those implementing an interface actually) with a CacheMonitor. The monitor is a daemon thread that expires the cache once in a while and reloads the data from the database.
As for the business layer, the SBs and EBs read the data through cache manager. The cache manager exposes methods such as -
DictionaryObject getValue(ClassType, id)
Collection getValues(classType)
that hide the fact every DictionaryObject has its own cache.
Hope this helps.
 
Paul Lester
Ranch Hand
Posts: 40
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Jan, about the only choice here is JNDI with a serializable object. If you use Singleton and you get into a clustered environment, you have no way of guaranteeing that there will be only one instance of the object. You will have one instance per JVM that the cluster uses.
Of course, the JNDI approach is slow, but it is a lot safer than using a Singleton. I use the JNDI approach and haven't seen any harm, but my system is an internal system and not subjected to very heavy load.

Paul
 
Kyle Brown
author
Ranch Hand
Posts: 3892
5
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Not quite, Paul -- he's thought ahead to using JMS to keep the clustered caches synchronized as per the Propogate Cache Updates Pattern. As I note in the pattern writeup, I've helped build this in customer sites several times and it works fine.
Kyle
 
Paul Lester
Ranch Hand
Posts: 40
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks Kyle, I'll read the white paper. I've not used JMS, yet. I haven't had a use for it.
Regards,
Paul
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!