1 Reply Latest reply on Jun 2, 2009 2:27 PM by swd847

Seam and second level cache

gonorrhea Jun 2, 2009 8:45 AM

JOrshalick wrote an informative article on using 2nd level cache with Seam (well, actually Hibernate, but in a Seam app anyways).

http://solutionsfit.com/blog/2009/04/06/second-level-caching-still-an-effective-performance-tuning-technique/

What I'd like to understand are two items:

1) why does he (or others) prefer EHCache over JBossCache? He states I find it simple to use and it is fully supported by Seam’s multi-layered caching solution. But according to this wiki by BStansberry, If you use more than one JBoss AS instance to run your JPA/Hibernate application and you use second level caching for read-write entities, you must use a cluster-aware cache.

2) The goal of the optimization in Orshalick's article was to prevent multiple db hits for a HtmlSelectOneMenu read from multiple LRCs:

The problem is that the query that loads the CreditCardType instances into the conversation context executes every time a new conversation requests the dropdown list. This can cause the initial page load to lag.

Why can't we simply outject the List to SESSION context? wouldn't that solve the same problem? The only problem with this solution is synchronizing with table changes from an external source/app (i.e. preventing stale data in the HtmlSelectOneMenu component). If the data is read-only or read-mostly, this may not be much of a concern.

3) How exactly does the eviction policy and refresh/resync strategy work when using EHCache, for example? What happens if there is an external insert into the table that is read from for the HtmlSelectOneMenu component? When/how is that cache region updated? Or is it not in his example's case b/c he configured @Cache as CacheConcurrencyStrategy.READ_ONLY.

4) Does this strategy apply mostly to drop downs? Any other components?

1. Re: Seam and second level cache

swd847 Jun 2, 2009 2:27 PM (in response to gonorrhea)

1)
I don't know anything about ehcache, but jboss cache does require quite a bit of configuration (there is an official hibernate howto around somewhere, but it is hard to find on their website). According to the website ehcache is cluser aware. All clustered caching solutions require careful configuration to make sure the cache is set up to have the scematics you require.

2)
In this particular instance, it probably make no difference, as credit card types are not going to be changed very often you could just outject it to application scope and be done with it. But then you wouldn't have learnt anything. Incidently the second level cache still sufferes the same problems with syncronisation from an external source as what you would have outjecting to application scope.

3)
If there is an insert from the current app the query cache is wiped clean, the second level cache is not affected. If there is an external insert it will not be visible until the data in the query cache has expired from the cache. Eviction policies are configured using you normal cache configuration file.

4)
No. You have to make informed decisions based on your app's usage patterns. If a list is used a lot and rarely updated then yes, it is a good candidate for caching. Also the second level cache is not a magic bullet, for instance if you are loading the owner of a one to one fk reference from the other side hibernate will always issue a db call, even if the owner is already loaded into the persistence context.
Actions