In implementing the Coherence POC for JSR107 I had trouble with the concept of the "NotificationScope".
Such a concept does not exist in Coherence and I have trouble understanding the intended semantics in an implementation agnostic world.
I find it troubling why an application would need to distinguish between "local" and "remote" events. In the general where data is homed seems purely an implementation detail and exposing this to consumers seems unnecessary. From a semantic point of view all data should be equal since the specification makes no statement of "homing" of data.
In some implementations supporting re-partitioning, data homing may move from node to node. It would introduce very strange non determinism if delivery of events were determined by transient properties such as the homing of data.
To be clear. Implementers may want such distinctions for internal purposes, but surfacing to the API is a mistake in my view.
We could chose to follow something like the CoherenceObservableMap pattern. Replace
boolean registerCacheEntryListener(CacheEntryListener<? super K,? super V> cacheEntryListener, NotificationScope scope, boolean synchronous)
by 2 APIs
boolean registerCacheEntryListener(CacheEntryListener<? super K,? super V> cacheEntryListener)
boolean registerCacheEntryListener(CacheEntryListener<? super K,? super V> cacheEntryListener, Filter filter, boolean isLite)
This would allow implementers to provide custom filters for e.g. NotificationScope as above but not enforce this concept where it does not make sense. NotificationScope could be removed from the API and replaced with Filter (Coherence link provided for reference/POC only).
I would also like to eliminate the synchronous flag - listeners (as specified in the spec) should always be asynchronous
Closed because subsumed by
interceptors shot down
Regarding local and remote events, in GemFire this is solved through subscription model where if you don't register interest in some cache or key, then you will not get events for it. The difference in how processes operate whether they're client or server makes sense to me. Is there any provision for specifying that distinction? I would imagine that some clients are going to be temporary and would not be expected to hold data or 'participate' in caching but simply 'consuming' the data and events.
The "remote" in NotificationScope in Ehcache is used for two things:
Although the concept of a filter does sound interesting I'm not sure it really solves the problem here. Assuming no use of impl specific functionality there isn't really much if any useful data that the filter can make it's decision with. For example there is no way of knowing whether the event is "remote" or not. I'm not advocating for adding such "isRemote" functionality to the API either. Unless we can come up with useful Filter implementations that can be written entirely against the 107 API then I think we should just ditch the NotificationScope without adding anything else and allow implementations that need to distinguish between remote/local events to do so in their own ways.
+1 on removing the synchronous boolean as well btw.
The change to the API has already bean made and committed. Filter is there and is a generic enough interface to allow concrete implementations to be as complex as needed - it is equivalent to the Runnable interface...
Although I appreciate that the changes have already been made, I fail to understand what the Filter interface and it's associated usage is buying us here.
Since there is no additional data exposed to the Filter that isn't also available to the users listener implementation what's the advantage of having the filter inside the api over just having the user implement the filter logic themselves (potentially by just rolling the logic in to their listener impl?
Since we have now restricted listeners to firing synchronously in the path of execution I agree that filters no longer add value. I agree they may be removed
Remove Filter class and it's usage. Closes #43