executeUpdate causes coarse cache invalidation

We could take advantage of the returning clause to retrieve the list of mutated IDs and limit cache invalidation to the real affected rows. Note we plan on implementing explicit support for this, see: .

I've tackled this issue by declaring a second persistence unit which has L2 caching disabled and directing my bulk updates/inserts through it. The first persistence unit has L2/query cache enabled and is blind to what ever happens through the other persistence unit. It opens the door to cache synchronization issues and is not a perfect solution, but it does give the developer the necessary control over query cache invalidation.

if you are computing the query inside java application the I hope you are using org.hibernate.SQLQuery object fon r executing the query. In that case you could use any of the following method to acheive the same thing.
SQLQuery SQLQuery.addSynchronizedQuerySpace(String querySpace)
Adds a query space for auto-flush synchronization.
SQLQuery SQLQuery.addSynchronizedEntityName(String entityName)
Adds an entity name or auto-flush synchronization.
SQLQuery SQLQuery.addSynchronizedEntityClass(Class entityClass)
Adds an entity name or auto-flush synchronization.

2 Steve :
This behaviour should be documented a switched off by default, and senior developer can make decision, if he switches it on. I would like to have this possibility.

Why do you thing, that this behaviour is incorrect ? There is a lot of ways how to update data outside of hibernate ( for example : triggers ), so the senior developer have to remember for which table can use cache and for which cannot. I've a big database ( 1TB ), about 400 users and 10 application servers in cluster, changes are going too quickly, so I've caches only for several codelist tables.

> How do you correlate a read-only cache and things that can be updated?
Things that can be updated don't have cache.
Cached read-only tables/codelists are changed (only operations are INSERT and UPDATE of valid_to-column ) during system maintainance time.

2 rajesh : Your solution is not for me, because I don't have SQL-query extracted outside java-code. I compute this query inside of application.

Hi All,
I have found a solution to the problem described.
Hibernate provides a <synchronize> tag to specify what all are the tables that are affected becuase of the bulkupdate.

If we are specifying the <synchronize>with table name hibernate only invlidate the cache of the table present in the synchronize table.This will avoid clearning of all the cache regions including the read only cache.
For achieving this, <synchronize> should be added to the <sql-query> during a bulk update or a delete.

Eg:
<sql-query name="queryname">
<synchronize table="tablename"/>
update tablename set value = ?
</sql-query>

The synchronization should be done on the affected tables because of the update. There can be one or more synchronize tags within the same block depending on what all tables got affected. This will result in cache invalidation of only those tables which are synchronized; otherwise the entire cache region is invalidated.

Note: Hibernate does a flush of the pending data for synchronized tables (from insert/update queue) before actually doing the synchronization. So the flush is triggered automatically for those data in the insert/update/delete queues where the affected tables are synchronized.

We could get this documented in hibernate reference documentation.