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.

On 01/05/2016 06:51 PM, Scott Marlow wrote: > On 01/05/2016 12:36 PM, Steve Ebersole wrote: >> 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. > Thanks for the answer, this is exactly what I needed to know. > >> 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. > Yes, I agree (based on your explanation). > >> 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. > This would be a nice performance enhancement for clustered environments, > as the (no removals allowed) immutable-entities cache would not need to > be cluster aware. ATM in Infinispan 2LC there's no optimization for Immutable entities, because the necessary handling of removals does not differ much from updates. In the past, the immutable-entities configuration was added as Galder suggested that in 4.x implementation these can use non-transactional cache, but in the end the implementation had flaws causing inconsistencies. For Immutable and never removed entities, you can AFAIK safely use local cache. However I am not aware of any means that would mark entity as never removed, or relax the consistency for removals. Radim > > _______________________________________________ > hibernate-dev mailing list > hibernate-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev -- Radim Vansa <rvansa(a)redhat.com&gt; JBoss Performance Team _______________________________________________ hibernate-dev mailing list hibernate-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev