• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Caching implementation strategy

 
Greenhorn
Posts: 11
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I've been researching the various caching options to limit our roundtrip calls to the database. I've kind of taken a liking to JbossCache as a solution, but was hoping some fine folks might suggest a code-based implementation approach for using the library.

Setup: We are currently refactoring a standard web app built on Spring MVC, Tiles, JSP. The site is 'skinned' depending on the logged in user (by state of user). Due to the 'location' dependent nature of the application, there are pieces of the application (header information, label values, dropdown list values, default field values for certain fields, etc.) which change depending upon the location of the user. Again, these could all be different between states (i.e. default may be 0.8 for a field in Texas, but 0.5 for the same field in Florida). Some of this will be accomplished via ResourceBundles defined by state (labels), but the architect has requested we cache much of the static reference data (dropdowns, etc). In addition, there are complex rules about some aspects of the UI. For example, if we choose Value A in a listbox, a new set of values is displayed in another radio group field. These are also identified as candidates for caching up-front on application startup.

The goal of the development effort is to make the application accessible outside of a purely 'web app' context. They're building out components to be used as web service endpoints that will mimic the workflow that is only currently supported by the web app. The end result is an application which can have services requested ad-hoc using standard XML input and output. The web app is the current model and will continue to be supported, but they're implementing a SOA-based approach.

Does anyone have some good design strategies for implementing a caching solution (patterns, abstract vs. interface approach)? This will be in a single JVM, so no replication is needed currently, though a library that could handle that for future use-cases would be nice. I like JBoss Cache/POJO Cache at this point, due to the hierarchical nature of its cache. I can store the default values of fields as such:

root/texas/defaultvals/field1/value
root/florida/defaultvals/field1/value
...
...

That seems to lend some flexibility w/how the data is stored/retrieved.
 
Rancher
Posts: 4803
7
Mac OS X VI Editor Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I'm not sure what you are asking. Generally, you can use someone else's cache implementation, or you can write your own.

I like one that I've implemented, its a WorkingSetCache based on Denning's work on locality and cache efficiency. Open source code at
http://pfarrell.com/java/pdflib.tar.gz

To get good performance, you have to engineer the design of the cache with the production environment. For example, many cache schemes use a LRU (least recently used) which is simple to program, explain and test. It usually works fairly well, but can fail badly in some cases.
 
Daniel McDade
Greenhorn
Posts: 11
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Pat Farrell wrote:I'm not sure what you are asking. Generally, you can use someone else's cache implementation, or you can write your own.

I like one that I've implemented, its a WorkingSetCache based on Denning's work on locality and cache efficiency. Open source code at
http://pfarrell.com/java/pdflib.tar.gz

To get good performance, you have to engineer the design of the cache with the production environment. For example, many cache schemes use a LRU (least recently used) which is simple to program, explain and test. It usually works fairly well, but can fail badly in some cases.



Pat, thanks for the feedback, and I apologize for the vague nature of my inquiry. I'm more speaking to how to design my solution, programmatically speaking. In other words, regardless of which library I choose (JBoss Cache, EHCache, OSCache, etc.) how should my application be structured to leverage their API? Should I simply define a CacheManagerUtil that acts as a wrapper for their cache-specific objects (CacheManagers, Caches, Elements, etc.)? Is there a more interface-based approach that could work as an alternative to integrate the cache implementation? Does anyone have an approach that worked for them successfully in the past?

Thanks in advance,
dannymac
 
Pat Farrell
Rancher
Posts: 4803
7
Mac OS X VI Editor Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I make using the cache transparent to users (aka other developers). Its an engineering decision which objects get cached. I put the cache in the BusinessObject layer, as part of the ORM. This approach is not 100% transparent to the users, for instance, if your Person object is cached, the normal access to an object via its primary key is
Person aper = Person.getFromId(primkey);
instead of the usual
Person aper = new Person(primkey);

 
Daniel McDade
Greenhorn
Posts: 11
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Pat Farrell wrote:I make using the cache transparent to users (aka other developers). Its an engineering decision which objects get cached. I put the cache in the BusinessObject layer, as part of the ORM. This approach is not 100% transparent to the users, for instance, if your Person object is cached, the normal access to an object via its primary key is
Person aper = Person.getFromId(primkey);
instead of the usual
Person aper = new Person(primkey);



Are you tagging your domain model objects with annotations to mark them as 'cacheable' or loading the target objects to cache via a properties/xml file? You mentioned ORM, so I assume you're doing it at the class level with some kind of annotation. We're not using Hibernate (or any ORM solution) so I was planning on loading everything on startup that is needed by the application. Candidate objects would be loaded from the DB via a configuration file. Does this seem reasonable? Should I keep the CacheManager as a static singleton reference? Inside a thread-local wrapper? I'm just throwing darts. Haha.

Our needs are for mostly static, read-only data, so I don't have a requirement to constantly sync-up the cache elements.
 
Pat Farrell
Rancher
Posts: 4803
7
Mac OS X VI Editor Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
My cache code has no automatic anything, no annotations. It takes a bit of code, which is easy to write.

Other cache systems may use annotations and try to automate some of the stuff.
 
Rancher
Posts: 43081
77
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
https://coderanch.com/how-to/java/CachingStrategies may be of interest.
 
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
reply
    Bookmark Topic Watch Topic
  • New Topic