[infinispan-issues] [JBoss JIRA] (ISPN-7165) CACHE_MODE_LOCAL is unsafe with L1 enabled

Dan Berindei (JIRA) issues at jboss.org
Thu Nov 3 07:26:00 EDT 2016


Dan Berindei created ISPN-7165:
----------------------------------

             Summary: CACHE_MODE_LOCAL is unsafe with L1 enabled
                 Key: ISPN-7165
                 URL: https://issues.jboss.org/browse/ISPN-7165
             Project: Infinispan
          Issue Type: Bug
          Components: Core
    Affects Versions: 8.2.4.Final, 9.0.0.Alpha4
            Reporter: Dan Berindei
            Priority: Minor


The {{CACHE_MODE_LOCAL}} javadoc says:

{quote}
In distributed mode, the modifications performed
during an operation in a non-owner node are going to L1, 
if it is enabled, otherwise the operation is a no-op in
that node.
{quote}


I see 2 problems with this:

# Remote get-triggered L1 writes go through an {{L1Synchronizer}} to ensure stale entries don't overwrite newer ones. {{CACHE_MODE_LOCAL}} ones don't have any synchronization, so they could overwrite an existing value with a newer one. To be fair, when reading values from an external source and inserting it in the cache, keeping the cache in sync is kind of tricky even with regular writes.
# Remote get-triggered L1 writes also register on one or more of the key owners as an "L1 requestor", so the owner knows whether it should broadcast an invalidation message when the value changes. (That's in the default configuration; with {{invalidationThreshold > 1}}, the owner will only send unicast invalidations to the individual requestors.) {{CACHE_MODE_LOCAL}} writes do not register on any owner, so their values may never be invalidated.

We should change {{CACHE_MODE_LOCAL}} to never write to L1. If the application wants to write an entry to the local node regardless of ownership, it should use {{SKIP_OWNERSHIP_CHECK}} too, and it should be aware that the cache will not perform the regular L1 invalidation for that entry.

Note that {{putForExternalRead()}} doesn't use {{CACHE_MODE_LOCAL}}, so it shouldn't be affected.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)


More information about the infinispan-issues mailing list