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. _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
