[infinispan-issues] [JBoss JIRA] (ISPN-8411) Add support for efficient removeAll

[Emond Papegaaij (JIRA)]

    [ https://issues.jboss.org/browse/ISPN-8411?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13478035#comment-13478035 ] 

Emond Papegaaij commented on ISPN-8411:
---------------------------------------

Thank you for the clear explanation. We are currently evaluating how to proceed. Changing the transaction mode requires some changes to our codebase (annotations) and a restart of our services.

While preparing our application to use read-write, we did get this warning:
{{13:29:03,808 WARN  [org.hibernate.cache.infinispan.impl.BaseRegion] (ServerService Thread Pool -- 67) Requesting TRANSACTIONAL cache concurrency strategy but the cache is not configured as transactional.}}

It seems Hibernate 5.x still requests transactional caches by default for Infinispan: https://github.com/hibernate/hibernate-orm/blob/master/hibernate-infinispan/src/main/java/org/hibernate/cache/infinispan/InfinispanRegionFactory.java#L425 . We've circumvented this problemen bij overriding the default using the {{hibernate.cache.default_cache_concurrency_strategy}} setting, which is documented as _This setting is very rarely required as the pluggable providers do specify the default strategy to use._


> Add support for efficient removeAll
> -----------------------------------
>
>                 Key: ISPN-8411
>                 URL: https://issues.jboss.org/browse/ISPN-8411
>             Project: Infinispan
>          Issue Type: Feature Request
>          Components: Hibernate Cache
>    Affects Versions: 8.2.8.Final, 9.1.1.Final
>         Environment: WildFly 10.1.0, WildFly 11.0.0.CR1, WildFly master, Hibernate 2LC
>            Reporter: Emond Papegaaij
>            Assignee: Galder Zamarreño
>
> Infinispan currently does not seem to implement an efficient way to clear an entire cache cluster-wide. This forces Hibernate to remove all entries one by one when a cache region needs to be cleared, for example when a buld CriteriaUpdate or CriteriaDelete is used.
> The behavior we are observing is:
> # All nodes in the cluster are queried for the keyset in a region
> # A lock seems to be in place for this region for the duration of the commit
> # The initiating node constructs a message with {{InvalidateCommands}} for all keys
> # This large message (230MB for 200k entries) is sent to all nodes in the cluster
> For large caches this can take very long. We had to increase the remote-timeout to 60 seconds to prevent timeouts. During this time, the entire cluster is locked an busy processing the cache invalidations. As you can understand, this is not a workable solution for us. On some places we can prevent the cache clear by updating the records one by one, but in other places this is not an option. 
> The corresponding report at Hibernate can be found here: https://hibernate.atlassian.net/browse/HHH-12036



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)