You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I have a specific use-case, where I would like to use a MultiLevel cache, where L1 is Local and L2 is Replicated, using no external datastore.
As a simple example I have 2 nodes in a cluster
I put a key on Node 1 and through the MultiLevel cache, it gets written to L2 and is replicated to to L2 of Node 2.
I get the key on Node 2 and subsequently update it
I get the key on Node 1, it is now stale in L1 but fresh in L2, doing get on Node 1 I only get the stale data from L1
My expectation was that the key in the L1 cache would be invalidated, when there is an inconsistency between L1 and L2, and the data in L2 is fresher. Or that I could at least somehow configure the cache to do that.
The reason for doing this, is I only care about the local data, and an update to a key on another node implies a migration (this is related to UDP). I am already using redis, but I believed I could get rid of it.
Am I correct that this use-case is not supported currently?
The text was updated successfully, but these errors were encountered:
Closing this issue because it is related to issue #50. Besides, there is an adapter that handles the multilevel invalidation already NebulexLocalMultilevelAdapter.
I think my issue is related to #50
I have a specific use-case, where I would like to use a MultiLevel cache, where L1 is Local and L2 is Replicated, using no external datastore.
As a simple example I have 2 nodes in a cluster
My expectation was that the key in the L1 cache would be invalidated, when there is an inconsistency between L1 and L2, and the data in L2 is fresher. Or that I could at least somehow configure the cache to do that.
The reason for doing this, is I only care about the local data, and an update to a key on another node implies a migration (this is related to UDP). I am already using redis, but I believed I could get rid of it.
Am I correct that this use-case is not supported currently?
The text was updated successfully, but these errors were encountered: