Normally during a native query the entire second-level cache is cleared unless it is explicitly stated which entities the query affects. In our situation we want to execute the following PostgreSQL command which clearly doesn't affect any entity. If the second-level cache is always cleared this can potentially cause a major performance issue.
{noformat}
SET statement_timeout TO 0
{noformat}
BulkOperationCleanupAction coordinates the cache cleanup. It uses the method affectedEntity() to check if a given entity is on the list of explicitly stated affected entities. If the list of affected entities is empty the entire cache is cleared, as can be seen here:
{noformat}
private boolean affectedEntity(Set affectedTableSpaces, Serializable[] checkTableSpaces) {
if ( affectedTableSpaces == null || affectedTableSpaces.isEmpty() ) {
return true;
}
{noformat}
As a workaround I implemented following method which adds a dummy entry to the list of affected entities, effectively preventing the cache cleanup.
{noformat}
public static void preventCacheCleanup(final Query query) {
query.unwrap(SQLQuery.class).addSynchronizedQuerySpace("");
}
{noformat}
These issues are somewhat related:
https://hibernate.atlassian.net/browse/HHH-8487
https://hibernate.atlassian.net/browse/HHH-9315
|
|
