Re: [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  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 >> > 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@lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
>
> --
> Radim Vansa 
> JBoss Performance Team
>
> ___
> hibernate-dev mailing list
> hibernate-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
___
hibernate-dev mailing list

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


-- 
Radim Vansa 
JBoss Performance Team

___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

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

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

[Scott Marlow]

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.

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

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.

 From Immutable javadoc:
"
Mark an Entity or a Collection as immutable. No annotation means the 
element is mutable.

An immutable entity may not be updated by the application. Updates to an 
immutable entity will be ignored, but no exception is thrown.
...
"

Scott

[1] https://issues.jboss.org/browse/WFLY-5923

___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [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  > 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