Your conception of entity caching (and associated replication) is incorrect. The purpose of the cache is to allow 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 -- that is the job of the EntityManager.
You need to use a shared database.
Using a replicated cache just means that when the EntityManager on node2 checks its cache, its cache includes any updates made by the EntityManager on node1. Otherwise it could read stale data from the cache. But both EntityManagers need to be working with the same underlying database.
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:
implies replication via the cache is persisted ( ? )
I've got a test setup with 2 machines in a cluster which seems to work (I can see the cache replication working via JMX console) but what I also see despite entities being replicated in the cache, the DB is still always being queried (I can see the query count increase in the DB (MySQL) tools). I would expect not to see a DB access for cached entities. Any thoughts on that one ?
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 database from which the entities come is already a persistent store.
As to why you're still seeing queries, that's hard to say. Some possibilities:
1) The queries are not of the simple 'select record from table where primary_key = ?' type. In that case Hibernate will be executing queries to determine the PK of entities that match your requirements, and then will either get then entity from the cache or from the DB. (Note: you can also configure the EntityManager to cache the results of such queries.)
2) Entities are being evicted from the cache to save memory (it has an eviction policy configure). If the entity is evicted, the EntityManager will have to go back to the DB.
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.
I've got the database replication setup now for my test application so I will investigate the query issue further now.
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 to configure ?
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.
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.