Some questions about the behavior of AddInternal function

[xingwen1987]

As I understand it, if user add a cache to the CacheManager, the CacheManager should add cache item to each handle.

But the current implementation only add cache item into the last registered handle. [code here]

Here is a scenario, ServiceA is a cache write service, which registers a RuntimeCacheHandle and multiple RedisCacheHandle (Redis1 ~ Redis5) to write, and ServiceB is a cache read service, which registers a RuntimeCacheHandle and one RedisCacheHandle (Redis1).

if ServiceA use AddOrUpdate method to add a cache item, according to the current code logic, this cache item only write to Redis5, When ServiceB wants to get the cache item written by ServiceA from Redis1, this cache not exist because ServiceA not add this cache into Redis1.

I want to understand the intention of this design, looking forward to your reply.

[xingwen1987]

The current quick solution is to call GetCacheItem function immediately after ServiceA AddOrUpdate, so that all cache items will be written to all handles, but this writing method will cause great ambiguity.

I guess if the purpose is to control. can we set a direction for each Handle, ReadWrite, WriteOnly, and ReadOnly?

• When adding, filter out the ReadWrite and WriteOnly handles and add them one by one.
• When reading, filter out the ReadWrite and ReadOnly handles and read them one by one.

Will this help improve the robustness of the component?

[MichaCo]

Hey @xingwen1987,
Thanks for the question.

The read through logic of CacheManager is intentional to make it almost impossible to end up in a scenario where I write an item to first and second cache handle and then the 2nd write fails with a network error for example.
In that scenario, I might have to add additional logit to a) detect that and b) role back the write from the first cache handle.
If I would leave the data in one handle, apps could see that as a bug/error state because the cache item actually does not exist in the "master".

Long story short, this design is like that to keep the implementation simple and have no risk for data errors.

Now to your scenario.
You configure 2 different Redis caches?
My first question would be why would you do that?
I don't mean that negatively. I really would like to know your use case here because I think you might have a problem to solve but maybe the wrong idea ;)

Anyways, the main reason to use Redis is to have a distributed cache in the first place. What you describe is distributing cache data onto multiple "nodes".
That's not "the job" of a client application or a library like CacheManager. Redis does that very well and is meant to do that part.

[xingwen1987]

I'm sorry for not getting back to you sooner. I had a long National Day holiday, and now I am back to work.

In that scenario, I might have to add additional logit to a) detect that and b) role back the write from the first cache handle.

First, I totally agree with your opinion on the mentioned multi-handle storage. Yes, we cannot guarantee that every handle will be work fine in real-time, and defensive code increases overall complexity.

But in practice, if the user does not use CacheManager as a cache manager from the project beginning and want to integrate it, they need to replace a lot of cache-related logic and objects hidden in the business codes, which is a huge breaking change with full risk, this is a key obstacle!!

From a practical perspective, if CacheManager can manage existing cache instances and share cache values with existing cache instances, it will increase its ability and reduce integration difficulty, wouldn't it be a win-win situation?

You configure 2 different Redis caches?
My first question would be why would you do that?

Our production environment has multiple Redis clusters, including RW (read-write) clusters for our own business and RO (read-only) clusters for obtaining data. Large-volume data synchronization in some scenarios is achieved through Redis, so our system will connect to many Redis.

If CacheManager can use the Name field in CacheManager Settings as the target cache and set RW or RO role for each handle, combined with what I said above, CacheManager will simplify cache connections and operations from another dimension and increase the utilization rate of it.

here is a sample:

for RW:
_cacheManager.Instance("Redis1").Set("test-key", "test-value");
var cacheVal = _cacheManager.Get("test-key");

for RO:
var bigData = _cacheManager.Instance("Redis1").Get("test-key");

for set-up:

var builder = new CacheConfigurationBuilder();

builder
   .WithBackplane(typeof(CustomRedisCacheBackplane), "RedisName1", "RedisName1CacheBackplane")
   .WithHandle(typeof(CustomRedisCacheHandle<>), "RedisName1", true, redisCacheInstance_1, DataRole.ReadWrite)
   .EnableStatistics();

builder
   .WithBackplane(typeof(CustomRedisCacheBackplane), "RedisName2", "RedisName2CacheBackplane")
   .WithHandle(typeof(CustomRedisCacheHandle<>), "RedisName2", true, redisCacheInstance_2, DataRole.ReadOnly)
   .EnableStatistics();

[MichaCo]

Hey,
Thanks for the details and more information about what you have in mind.
I don't believe that this library is the right place to handle those kind of "syncs" or different updates though.
That looks like something very custom.

I also don't plan to support ReadOnly Redis servers. The current implementation requires lua and some other commands to work, The StackExchange.Redis client also requires some commands to be available...

Currently I have no plans to make that more complicated as it already is.
Sorry

[xingwen1987]

Thanks for the feedback.
I will fork CacheManager and start related research from the integration perspective.
If there is any process, I will let you know.