Understanding (invalidation) cache behavior for a REST client

[wesmith80]

Here's my config:

Cluster_Node_A = {key1, key2, key3}

Cluster_Node_B = {key4, key5, key6}

Database={key1, key2, key3, key4, key5, key6}

Loadbalancer fronts the Cluster

Sequence of events:

1) REST client requests for key1

2) Loadbalancer directs client  request to Cluster_Node_B

3) Cluster_Node_B does not have the requested data.

Question: Does Cluster_Node_B go to Cluster_Node_A, get the data, and serve it to the REST client or does Cluster_Node_B go to the Database to get it?

Additional info: We are doing a write-through to the database every time we write to cache, i.e., writer threads waits while data is written to Database

Hope my question makes sense. Please let me know if you need more info. Appreciate your help!

[wesmith80]

Basically I'm trying to decide between HotRod and REST clients and my understanding is that with HotRod (for a distributed cache) the client has knowledge of what keys are in what node in the cluster, so a cache miss is avoided.

[rvansa]

In distribution mode, if the key is not on local node (and it should not be hashed there), the entry is retrieved from remote node rather than going to the database.

In invalidation mode, you would go to the database if it's not found in memory.

If you can use HotRod, use HotRod, this is the native and most optimized protocol. REST would be recommended if the client is e.g. in JavaScript where you could not use HotRod.

[wdfink]

I would recommend HotRod as it knows which node to ask for a key. Also there is no need for a loadbalance as HR will do the work.

Decision for Invalidation or Distribution depends on your use-case and what approach (REST, HR) you use. Invalidation can be slow if you doing a lot of writes.