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

[Sanne Grinovero]

Since one can delete an immutable entity, and then create (insert) a
new one to replace it, from the point of view of the Cache the entry
is not immutable and needs to be treated with the usual safety and
consistency concerns.

As Radim suggests, optimizations like using a local cache might make
sense in many practical use cases as the application developer might
take advantage of knowing that he's not doing such a an update, but
this shouldn't be automagically enabled by default as Hibernate can't
tell if it's safe.

Sanne


On 6 January 2016 at 08:41, Radim Vansa <rvansa at redhat.com> wrote:
> 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 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.
>
> 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 at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
>
> --
> Radim Vansa <rvansa at redhat.com>
> JBoss Performance Team
>
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev