Hi Brian,
Thank you for your reply.
OK I guess I am trying to understand what EJB3 plus the clustered entity
caching is doing in place of the standardjboss.xml commit options i.e. what is
the equivalent commit option in terms of its behaviour ?
I'll investigate the DB access further.
BR,
There's no relationship between EJB3 entity caching and the standardjboss.xml
stuff (which is for EJB2).
Not sure why you're seeing database activity; can only suggest you turn up the
logging level on org.hibernate if you want to better follow what the
EntityManager is doing.
View the
Hi - I am also new to the clustering aspects of JBoss and suffering similar
confusion I think about entity persistence in a cluster.
Section 10.3 here:
http://labs.jboss.com/file-access/default/members/jbosscache/freezone/docs/1.4.1.SP2/tutorial/en/html_single/index.html
implies replication
The CacheLoader discussed on the link you posted is not meant to be used with
EJB entity caching. A CacheLoader allows the cache to maintain a persistent
form of some or all of the data the cache is managing. In the case of entity
caching, having the cache do this is redundant; the underlying
Thanks for your reply.
Thanks for clearing up the confusion re. the entity clustering. A (simple)
shared DB is no good for my application as it would be a single point of
failure so it looks like a need to either use the DB replication or DB
clustering. Thanks - I can look into that then.
OK. Next brain-hurdle:
What is the relationship between the distributed EJB3 entity cache and the
commit options etc defined in standardjboss.xml ?
I'm still seeing DB access even for queries by explicit primary key value for
objects in the cache and wondering if there are other thing I need
Your conception of entity caching (and associated replication) is incorrect.
The purpose of the cache is to all the EntityManager to save database reads by
letting it cache some data in memory. Writing to (or even reading from) the
database is not a part of an entity cache's intended behavior
