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

[Radim Vansa]

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