Handling null
Values in Quarkus Cache Backends
#42940
Replies: 5 comments 7 replies
-
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 ( if we use the cache api programmatically, I guess we need option |
Beta Was this translation helpful? Give feedback.
-
@geoand did I remove your comment by mistake ? |
Beta Was this translation helpful? Give feedback.
-
Wouldn't option |
Beta Was this translation helpful? Give feedback.
-
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:
|
Beta Was this translation helpful? Give feedback.
-
@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. |
Beta Was this translation helpful? Give feedback.
-
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 handlingnull
values.The Problem
The core issue is straightforward: what should occur when the expensive computation intended for caching returns
null
? The options are:null
value.null
value.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 anull
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:Configurable
null
Strategy: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.Modify
get
andgetAsync
Implementations:null
. This needs to change if we allow cachingnull
. This applies to Redis and Infinispan; Caffeine’s implementation needs verification.Distinguish Cached
null
from Cache Miss:get
andgetAsync
methods to differentiate between a cachednull
value and a cache miss.Related Issues
Any other option, opinion, or idea to handle
null
values effectively and homogeneously.Beta Was this translation helpful? Give feedback.
All reactions