Hi,

I plan to use Hibernate with JPA API inside an EJB container with a level 2 cache.

I'd like to modify database with native sql statements or use triggers that modify data or delete rows.

I understand that the level 2 cache doesn't handle modifications that are done out of the scope of the entity manager and doesn't update the cache. How to update the level 2 cache ? I've searched for a solution about this but I didn't find any information about this.


If I know which entites have been modified by the statements, is there any solution solution to notify the level 2 cache that these objects have been modified ? Reset on the whole cache is not a solution.

Does anybody knows a solution or has any link for this problem ? How to handle this problem ?

Thanks,
Mickael

Look at public void evict(Class persistentClass, Serializable id) throws HibernateException in SessionFactory. However, my favourite solution is to have an eviction policy that takes care of this periodically but I understand it is not a feasible solution in some cases.



Farzad-

Thanks for your answer.



I'd prefer to use JPA API and not hibernate extensions.



You are true, this solution is not adapted if you need a transactionnal cache.

Mickaël

To the best of my knowledge L2 caching is not a part of JPA. You will anyways have to use proprietary APIs to manipulate it.



I didn't get this one. What's the deal with a transactional cache? Why would you need a transactional cache?



Farzad-

Lets take as an example an application deployed in a cluster, each node's accessing the database with JPA and a level 2 cache.

Some entities have an attribute for applicative locking and this locks may be modified by triggers in the database. Maybe hundreds of locks may be modified by a single request with a complex filter, it is important to use a SQL statement instead of getting a lot of objects and iterating over the collection to modify locks one by one.

I want all caches of all nodes to be updated as soon as I commit in one node. I don't want another node finding in its level 2 cache an entity without lock if a lock has been put in the database. That's what I understand by "transactionnal cache", a cache that is replicated in the transaction scope.

The trigger that modifies locks may write in dedicated table the list of modified nodes, I thought I could use this list to evict all nodes from the cache.

Hibernate updates L2 cache only after the transaction commits, a transactional cache has nothing to do with that. What you need is a good distributed cache, probably something with synchronous cache invalidation. You will still need to use a proper isolation level on your db connection so that you prevent concurrent modifications and eliminate racing conditions.



Farzad-