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

[Steve Ebersole]

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> 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.