Seam and 2nd level db cache

[gonorrhea]

Section 30.1.7 of the Yuan 2nd ed. book covers using 2nd level db cache with Seam.

To improve performance, we should cache the entity beans representing those frequently accessed records in the application memory, instead of making repeated db roundtrips for the same bean objects.

There is a @Cache annotation in the example in the book which I'm assuming is this class org.hibernate.annotations.Cache.  As I understand it, JPA does not support 2nd level cache (see this My Link).

So assuming you are using Hibernate as your persistence provider for JPA, what do you describe as best practices regarding using 2nd level cache with Seam apps?  Does it only make sense in a clustered envmt?  Does it only make sense to use the @Cache annotation for entities that are mostly read-only?  Are there any exceptions to that rule?  Maybe I should re-read this section in the Bauer/King book on 2nd level cache.

And what about the <s:cache> tag, which I'm assuming is new in Seam 2.1...

[gonorrhea]

yeah, this stuff is complicated as it states in the Seam ref doc.

anyways, here's a concrete example from JBoss in Action:

@Entity
@Table(name="CATEGORIES")
@Cache(usage=CacheConcurrencyStrategy.READ_ONLY)
public class Category implements Serializable {
private Long jpaId;
private String categoryName;
// ...
}

Then it states the following:

Note that only the READ_ONLY and TRANSACTIONAL options are available with JBoss Cache.
If you want to use READ_WRITE or NONSTRICT_READ_WRITE, you’ll have to use a different
cache implementation.

So why wouldn't you use @Cache(usage=CacheConcurrencyStrategy.TRANSACTIONAL) for all entities?

CacheConcurrencyStrategy.TRANSACTIONAL Guarantees full transactional isolation up to repeatable read. Use this for data that is mostly read but where it is critical to prevent stale data if an update does occur.

Mostly read (as in reports use cases?)  So I imagine if you used @Cache(usage=CacheConcurrencyStrategy.TRANSACTIONAL) for entities that JPA exercises full CRUD on them, then there would be a performance penalty?

And would you (or must you) use CacheConcurrencyStrategy.TRANSACTIONAL with a Seam app deployed in a cluster only?  Or what about stand-alone server?

[klowtherjr]

Arbi,

Good to see you are getting on well after NCM.  Been a while since we last talked.

You wouldn't want to use TRANSACTIONAL when the cached data will never change as you'll incur a penalty for no reason.  What TRANSACTIONAL gives you is a check to ensure the data is not stale in the event it does change.  I imagine READ_ONLY to be used for static lookup tables like statuses and the like where the values will never change during a run of the application (only during down time).

I could be wrong, but I don't think the deployment scenario matters as much as how the data is going to be used in the application.  I think the deployment scenario of the application is irrelevant for the most part.  I hope this helps.

[gonorrhea]

Hey Ken, thx for the reply.  I had to look you up on linkedin but now I obviously remember you as the WorkPoint consultant.  I remember that hotdog palace with Andrew we went to :)

So what are you doing on this Seam forum?  Doing Seam dev nowadays?  Big learning curve with the whole JEE and/or JBoss middleware development stack.

I think the JBoss Cache replicates/synchronizes the local (node) cache to every other node in the cluster.  According to the Yuan book: The JBoss Cache configuration contains quite a bit of configuration related to clustering and replicaiton.  I need to experiment with this but never find the time...