issue #2220 - client side caching PoC test 1

[tgrall]

Hi,

I have created a small Proof of Concept for Client Side Caching.

The ideas behind it:

• almost transparent for the application, as soo as the jedis.clientTracking is called & enabled the cache is done for GET and HGETALL
• it is really limited (currently all String and Hash are cached when used by a client connection (Prefix is not used)

Q1: Should I continue with this approach, where I make the cache almost transparent for the user, but it will impact all the client code to check if the connection is using CSC ?

OR should I used a different approach where the client instantiate a new class associated to the client, and have to call JedisClientCache.get/hgetall. (this allows a better isolation of the code for caching)

Q2: if I stay with the current approach I do not know how to create a new connection on the fly with the same connection string information (needed for Pub/Sub client in RESP2) this is why I pass a Jedis connection to the ClientTracking method down to the Client code itself.

As I said it is just a PoC open for comments/discussions. (few hours of work during my PTO while kids are sleeping.. so probably need a lot more thinking....)

[sazzad16]

@tgrall

About Q1:

should I used a different approach where the client instantiate a new class associated to the client, and have to call JedisClientCache.get/hgetall. (this allows a better isolation of the code for caching)

This is not a strong opinion, but this sounds comparatively better to me.

BTW, how old are are your kids?

[tgrall]

I will test another implementation tomorrow morning.

17/19/21 2 of them are coding a lot (java, node and more ... they have started with Minecraft programming)

[sazzad16]

Your kids are not that kid then. Congrats!

[github-actions]

This pull request is marked stale. It will be closed in 30 days if it is not updated.

[sazzad16]

#3757