Is CaffeineCache.clear threadSafe?

[geekthread]

Hi Experts,

In our present code base we have taken an external lock before calling the clear method on CaffeineCache. We wanted to understand if an external lock is really required.

Would there be any downsides/impacts of removing the external lock.

@ben-manes

[ben-manes]

The cache itself is thread-safe and does not require any external locking for its own operations. However your external locking might be due to other custom logic in your application and be an unrelated requirement.

[geekthread]

Hi @ben-manes ,

Thanks for the quick response. I have below queries as well:

1. If there are 2 different threads one is updating the cache and another is clearing the cache concurrently. Will both the operations be atomic?

2. As per JavaDoc of the clear method attached here
   
   Clear method is asynchronous and other threads might still see the cache entries. To clear the entries immediately invalidate method is recommended but both the methods call invalidateAll() internally.
   .
   Which of these method is recommended for cleanup.?

3. If the clear operation has started and some put operation was submitted in the meantime would the clear operation be atomic (i.e. put operations don't impact the in progress clear operation).

[ben-manes]

Hi @geekthread,

1. If there are 2 different threads one is updating the cache and another is clearing the cache concurrently. Will both the operations be atomic?

The per-entry operations will be atomic. The clear operation performs a Map.computeIfPresent to remove the entry by returning null. However, atomicity means that no thread will observe intermediate state during an operation, which require that the clear operation blocks writes to all entries until it completes. That is not true of any ConcurrentMap in Java, only for its Collections.synchronizedMap(map) decorator.

2. As per JavaDoc of the clear method attached here

This is not our documentation, so I am unsure if my answers will be satisfactory.

Clear method is asynchronous and other threads might still see the cache entries. To clear the entries immediately invalidate method is recommended but both the methods call invalidateAll() internally.

We do not clear asynchronously, so this sounds like your implementation details. The limitation in our cache is that ConcurrentHashMap iterators do not expose new entries that may be established by in-flight operation, such as a compute or put. This means that our invalidateAll operation is not linearizable because we need the entry to perform additional housekeeping for a bounded cache. That differs from the lower level ConcurrentHashMap.clear() method which does observe these in-flight mappings and blocks. As we lack an api for that, we decided not to fork the hash table implementation to gain that detail of access. Do note that an unbounded cache, e.g. Caffeine.newBuilder().build(), delegates to the map's clear and therefore is linearizable.

Which of these method is recommended for cleanup.?

These look equivalent to me.

3. If the clear operation has started and some put operation was submitted in the meantime would the clear operation be atomic (i.e. put operations don't impact the in progress clear operation).

For a bounded cache and inserting an entry, the the iterators would not expose this mapping and therefore the clear operation would not be impacted. If the entry was being updated then the iterator would provide this mapping and the clear operation would block to atomically remove the entry. For an unbounded cache both an insert and update would block due to ConcurrentHashMap.clear() providing stronger linearizability support.