Re: [hibernate-dev] should immutable entities in the second level cache be invalidated when they are removed from the database?

Sorry Scott, I am not sure I understand exactly what you are asking. I will try to answer what I think you are asking as best I can.. On Tue, Jan 5, 2016 at 9:35 AM Scott Marlow <smarlow(a)redhat.com <mailto:smarlow@redhat.com>> wrote: I missed adding the WildFly clustering configuration for the Hibernate immutable-entity cache. I opened WFLY-5923 [1] for adding the cache but am unsure of whether org.hibernate.annotations.Immutable means that the application handles clearing the 2lc of stale immutable entities or if that should happen automagically when immutable entities are removed from the database. Perhaps there is a confusion that an immutable entity can in fact be created and deleted? Immutable simply means the state of an existing entity cannot be changed. In SQL terms, if you will, we can have an INSERT or a DELETE but never an UPDATE.

If an application has asked that Hibernate cache data, the expectation is that Hibernate would handle the caching of that data not the application *so long as it knows about changes to the cached data*. Now if by "when immutable entities are removed from the database" you are asking what should happen when cached data is changed in the database directly, that answer is always the same and the question of (im)mutablity is completely irrelevant there: if the underlying data is changed directly in the database it is up to the application to make sure that the cache is consistent with those outside changes. In a cluster, I expect that the performance of caching immutable-entities, would be faster if we assume they will not be invalidated from the 2lc (e.g. let applications clear them from the cache). I think really this comes down to the question of what "invalidated" means to the underlying cache and how a deletion of data correlates to that. But my guess is that the invalidation still needs to handled (and propagated) to properly handle the removal case.

Since we are using Infinispan for the 2lc in WildFly, I would like to use an Infinispan simple-cache for immutable-entities, which does no invalidation. However, just because I would like to do this, doesn't make it right. :-) Which is why I'm asking, what the design intention is, so I can configure the WildFly clustering configuration (for immutable entities), to align with the intent. Right, which is what I am trying to describe I guess in my previous paragraph. Based on my (granted, very limited) understanding of Infinispan I assume we still need the invalidation. One possible option is to allow the application to configure whether they expect removals from an immutable dataset.