I like Dinesh's middle ground proposal, since this feature has valid uses.
I'm not familiar with the row caching module, but would it make sense to
take this opportunity to expose this feature as an optional Row Caching
Module, disabled by default with an optional on-heap Caffeine
implementation?
The API would look something like:
RowCachingAPI {
- onRowUpdated(RowKey, Mutation) -> cache row fragment
- onRowDeleted(RowKey) -> evict cached row fragment
- onPartitionDeleted(PartitionKey) -> evict cached partition fragment
- Optional<RowFragment> getRow(RowKey) -> return cached row fragment
- Optional<List<RowFragment>> getPartition(PartitionKey, resultSize) ->
return cached partition fragment
}
This could be a potential hook for out-of-process caching.
Would something like this be valuable/feasible?
On Thu, Dec 14, 2023 at 8:09 PM Dinesh Joshi <djo...@apache.org> wrote:
> I would avoid taking away a feature even if it works in narrow set of
> use-cases. I would instead suggest -
>
> 1. Leave it disabled by default.
> 2. Detect when Row Cache has a low hit rate and warn the operator to turn
> it off. Cassandra should ideally detect this and do it automatically.
> 3. Move to Caffeine instead of OHC.
>
> I would suggest having this as the middle ground.
>
> On Dec 14, 2023, at 4:41 PM, Mick Semb Wever <m...@apache.org> wrote:
>
>
>
>>
>> 3. Deprecate the row cache entirely in either 5.0 or 5.1 and remove it in
>> a later release
>>
>
>
>
> I'm for deprecating and removing it.
> It constantly trips users up and just causes pain.
>
> Yes it works in some very narrow situations, but those situations often
> change over time and again just bites the user. Without the row-cache I
> believe users would quickly find other, more suitable and lasting,
> solutions.
>
>
>
