jodydonetti
commented
1 month ago Hi @shahaf-SG , sorry for the delay but I just came back from (very late) summer vacations 😅
Thanks for spotting it, you are in fact (partially) correct. But why "partially"? Let me explain.
When I wrote the first implementatio of the backplane LAZY was in fact how it worked. Then Auto-Recovery entered the scene, and I decided to tweak the internal behaviour to work better in all possible cases.
But now you may say something like "the PASSIVE mode had some negative aspects, aren't they still valid?" and to that the answer is that yes, they still are, BUT what I'm doing right now is not the PASSIVE mode I described there, which would mean going to get the value for the notified cache key on all the other nodes. What FusionCache does now is kind of a middle ground between LAZY and PASSIVE, you can call it LAZY++ (or PASSIVE-- 😬), because I go get the latest version of the data for that cache key BUT only if the value is already present in the local memory cache (L1).
Basically what I achieved is kind of the best of both worlds: FusionCache immediately updates the data in L1 ONLY if it is already there on that node, so that if cache key "foo" is in the memory cache of only 2 of 10 nodes, only those 2 nodes will get the data. This avoids the problems of the PASSIVE approach, at least as described in the (current) docs.
Anyway you are right in that the docs should be updated, thanks for pointing that out!
Will do as soon as possible, will update when I've done that.
Hope this helps.
The backplane documentation states that the lazy approach is being used (each client removes their local version of the data). However, when a set notification is received, the passive approach is used (each client updates their local version from the distributed cache).