Handling null Values in Quarkus Cache Backends

[cescoffier]

Hello,

(This is mostly for @karesti, @Ladicek, @geoand and @gwenneg - but every one is welcome)

In the past few months, several discrepancies have been reported regarding the handling of null values across the three cache backends proposed by Quarkus: Caffeine (in-memory), Infinispan, and Redis. To address these differences and ensure consistency, I suggest discussing the best approach for homogenously handling null values.

The Problem

The core issue is straightforward: what should occur when the expensive computation intended for caching returns null? The options are:

1. Cache the null value.
2. Ignore the null value.
3. Throw an error.

Caching the null value introduces ambiguity. When retrieving the value from the cache, it is unclear whether the key was not stored (cache miss) or if a null value was cached. This ambiguity can lead to observability issues but also recomputation (like in the Infinispan backend)

Ignoring the null value is also problematic, as it forces the expensive computation to be re-executed on the subsequent access.

Proposed Strategies

To improve the handling of null values, we can consider the following strategies:

1. Configurable null Strategy:

   • The cache backend can be configured to handle null values by either ignoring, failing, or caching them. If caching, we should ensure the observability layer does not misinterpret it as a cache miss.

2. Modify get and getAsync Implementations:

   • Update these methods to align with the chosen strategy. Currently, these methods retrieve the value associated with the key and recompute if null. This needs to change if we allow caching null. This applies to Redis and Infinispan; Caffeine’s implementation needs verification.

3. Distinguish Cached null from Cache Miss:

   • Adjust get and getAsync methods to differentiate between a cached null value and a cache miss.

Related Issues

• Issue 42184
• Issue 39547

Any other option, opinion, or idea to handle null values effectively and homogeneously.

[karesti]

Infinispan with Protostream supports caching null values, as Protostream understands and handles null values effectively. This is the expected behavior now. We do cache null values as states the cache extension documentation.

When using the caching API with annotations, users business method's semantics either returns a value or null. Whether the value is retrieved from the cache or calculated by the method, the result is indistinguishable to the user. The user and their business logic determine whether the method is expected to return null under certain conditions, whether a null value signifies an error, or if null should be cached to avoid costly computations. In this scenario, conditional caching like spring-cache is a good solution (1)

if we use the cache api programmatically, I guess we need option 3 too.

[karesti]

@geoand did I remove your comment by mistake ?

[geoand]

Added it back, no problem :)

[geoand]

Wouldn't option 3 be best from a user's PoV?

[Ladicek]

It seems to me that 1, 2, and 3 are not distinct options, but form together a cohesive whole. My only opinion is that 3 should be part of the SPI, but probably shouldn't be part of the API.

Also, here's a copy of this comment of mine:

I'm not sure if Infinispan can store null values, but the only option in Redis would be to encode it using some sort of a sentinel value, one that is super unlikely to be used by applications. For example, a string "io.quarkus.cache.redis.nullValuePlaceholder". Otherwise, all null values will in fact be cache misses, which is bad.

[cescoffier]

Yes, they are not exclusive; they can be combined. It was just a brain dump while refilling my mug.

[anadinema]

@cescoffier any decisions on it? This would be really helpful. In my head option 1 seems most desirable. And option 3 can be a good addon to it. But option 1 will give the control on how the application using the cache would like to go with it.

[cescoffier]

@anadinema I need to come back at it.

The summary would that 3 should be in the SPI. That's a first step. It would mean updating the underlying Cache service interface to follow the idea.

Then, when we have this, we can see if we want to expose that behavior to the user or not. It will at least fix the metrics issue as null won't be counted as cache miss.

@Ladicek @karesti You ok with that?

[Ladicek]

Sounds good. I agree we don't need 1 at the beginning.