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 <smar...@redhat.com >> <mailto:smar...@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@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev -- Radim Vansa <rva...@redhat.com> JBoss Performance Team _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
