Hibernate Infinispan Entity/Query caching

Question

I've been banging my head against the wall for a few days with this issue.

We are trying to implement Hibernate's second-level cache, using Infinispan. The application is running on JBoss AS 6, and using JTA transactions.

On our persistence.xml we have:

...
<!-- JTA configurations -->
<property name="hibernate.transaction.manager_lookup_class" value="org.hibernate.transaction.JBossTransactionManagerLookup" />
<property name="current_session_context_class" value="jta" />

<!-- Infinispan configurations -->
<property name="hibernate.cache.use_second_level_cache" value="true" />
<property name="hibernate.cache.use_query_cache" value="true" />

<property name="hibernate.cache.region.factory_class" value="org.hibernate.cache.infinispan.InfinispanRegionFactory"/>
<property name="hibernate.cache.infinispan.cachemanager" value="java:CacheManager/entity"/>
...

as defined here:

On our understanding this is the kind of cache that we need in order to do the following:

Use case one: We have records on a Database which will hold reference data. This data won't be changed for long periods of time (we hope :) ).

We want to cache these records as they are likely to be queried a lot. And as users query this data there won't be a need to go to the DB, since it should be cached.

For this case, is the cache type query cache, or entity cache? Being the query always the same, my understanding it's query cache as que query is supposed to return always the same results.

My query:

List<MyEntity> list = session.createCriteria(MyEntity.class)
        .add(Restrictions.eq("id", 1))
        .setCacheable(true)
        .list();

Use case two: A user gets a specific record from the DB, and he might update it. We would like this entity (or list of entities) to be saved on the user's session (login session) cache so if he updated this entity on the client, we wouldn't need need to make a select before the update. In this case, since we are saving specific entities, it's considered entity caching, right? If we want to store the

For that we're using:

@Cacheable (true)
@Cache(usage = CacheConcurrencyStrategy.TRANSACTIONAL)
public class MyEntity implements Serializable 
{
...
}

Am I making these assumptions correctly? If not, what is the approach here? I gues I'm making a big mess out of this.

Answer 1

Cross posted to https://community.jboss.org/message/751275#751275 - see my answers there.

Answer 2

The 2nd level (entity) cache is (making it simpler) a map base on the id as key. So each time reference data is "referenced" in other entity, the entity manager first check if it is present in the cache before going to the DB.

The query cache is a cache of result (ids) entities of a query. Then base on the ids it will retrieve the corresponding entity (preferably from the entity cache...), so you need the entity to be cached in the 2nd level cache to be useful.

For you first use case, reference data: you should annotated the entity as cacheable and use read-only strategy. The entity manager will put the reference data in the referencer entity when loaded, or use find(clazz,id) to get the reference data out of the 2nd level cache.

Case 2 is a bit more tricky. There is no "session" scoped cache (you need to manage it your self via SFSB or any upper level session mechanism if you need to keep intermediary result bind to user session). If you make the entity cachable it will be cached for every user on the server, the entity manager context has no direct link with a user.

If you want to prevent to make a select before updating, you should prevent the entity to reach unmanaged state (to prevent merge) via the extended persistence context. If the entity can often been updated by several user, the cache may decrease performance as it will take more time to manage consistency than going to the DB will take.

If you get performance bottle neck there you should first look on the related entity fetch and propagation annotation, if they are too large you make request or/and updating too much data from and to the DB.