[JBoss JIRA] (ISPN-7990) Provide a way to remove an entry from all indexes
by Sanne Grinovero (JIRA)
[ https://issues.jboss.org/browse/ISPN-7990?page=com.atlassian.jira.plugin.... ]
Sanne Grinovero commented on ISPN-7990:
---------------------------------------
Remember that if you don't know the type this is problematic:
* you won't know which indexes need to be cleaned up
* even cleaning up "all indexes" by id is troublesome as you might not have a full list to define "all indexes"
* without the type you don't know how to encode the key -> not matching the right key might lead to various mismatches, like delete the wrong data or not deleting it at all
The only safe solution I see is to know upfront which types might be used in this Cache; even so, what if the index was created by an instance having a different / out of date configuration ?
> Provide a way to remove an entry from all indexes
> -------------------------------------------------
>
> Key: ISPN-7990
> URL: https://issues.jboss.org/browse/ISPN-7990
> Project: Infinispan
> Issue Type: Enhancement
> Components: Embedded Querying
> Affects Versions: 9.1.0.Beta1
> Reporter: Gustavo Fernandes
> Assignee: Gustavo Fernandes
>
> This may be needed in some non frequent scenarios (happening during topology changes) where a write command cannot obtain the previous value to remove it from the index.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 3 months
[JBoss JIRA] (ISPN-7990) Provide a way to remove an entry from all indexes
by Gustavo Fernandes (JIRA)
Gustavo Fernandes created ISPN-7990:
---------------------------------------
Summary: Provide a way to remove an entry from all indexes
Key: ISPN-7990
URL: https://issues.jboss.org/browse/ISPN-7990
Project: Infinispan
Issue Type: Enhancement
Components: Embedded Querying
Affects Versions: 9.1.0.Beta1
Reporter: Gustavo Fernandes
Assignee: Gustavo Fernandes
This may be needed in some non frequent scenarios (happening during topology changes) where a write command cannot obtain the previous value to remove it from the index.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 3 months
[JBoss JIRA] (ISPN-7806) QueryInterceptor should not load entries from DC but context
by Radim Vansa (JIRA)
[ https://issues.jboss.org/browse/ISPN-7806?page=com.atlassian.jira.plugin.... ]
Radim Vansa updated ISPN-7806:
------------------------------
Description:
Currently in {{visitPrepareCommand}} the query interceptor is loading data directly from data container. That's wrong - if the entry is passivated/evicted, the previous value is incorrect.
As the data is not loaded (from DC/persistence) at current QI position, we should move QueryInterceptor after EntryWrappingInterceptor, CacheLoaderInterceptor -and xDistributionInterceptor (which may load the data from remote node),- and load the previous entry from context instead. The same approach should be taken for non-tx command, rather than relying on their return value.
**EDIT**: we should not move it below xDistributionInterceptor because on backup owner (which may be write-owner but not a read-owner) we would retrieve the updated value (affected by the current command), not the previous one.
There will still be issues if the command has SKIP_CACHE_LOAD flag: I suggest warning message if it doesn't have SKIP_INDEXING flag as well.
was:
Currently in {{visitPrepareCommand}} the query interceptor is loading data directly from data container. That's wrong - if the entry is passivated/evicted, the previous value is incorrect.
As the data is not loaded (from DC/persistence) at current QI position, we should move QueryInterceptor after EntryWrappingInterceptor, CacheLoaderInterceptor and xDistributionInterceptor (which may load the data from remote node), and load the previous entry from context instead. The same approach should be taken for non-tx command, rather than relying on their return value.
There will still be issues if the command has SKIP_CACHE_LOAD flag: I suggest warning message if it doesn't have SKIP_INDEXING flag as well.
> QueryInterceptor should not load entries from DC but context
> ------------------------------------------------------------
>
> Key: ISPN-7806
> URL: https://issues.jboss.org/browse/ISPN-7806
> Project: Infinispan
> Issue Type: Bug
> Components: Embedded Querying
> Affects Versions: 9.0.0.Final
> Reporter: Radim Vansa
> Assignee: Gustavo Fernandes
>
> Currently in {{visitPrepareCommand}} the query interceptor is loading data directly from data container. That's wrong - if the entry is passivated/evicted, the previous value is incorrect.
> As the data is not loaded (from DC/persistence) at current QI position, we should move QueryInterceptor after EntryWrappingInterceptor, CacheLoaderInterceptor -and xDistributionInterceptor (which may load the data from remote node),- and load the previous entry from context instead. The same approach should be taken for non-tx command, rather than relying on their return value.
> **EDIT**: we should not move it below xDistributionInterceptor because on backup owner (which may be write-owner but not a read-owner) we would retrieve the updated value (affected by the current command), not the previous one.
> There will still be issues if the command has SKIP_CACHE_LOAD flag: I suggest warning message if it doesn't have SKIP_INDEXING flag as well.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 3 months