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

[Scott Marlow]

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 at redhat.com
> <mailto:smarlow at 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.