Listener support is complex and hard to specify

[yannis666]

I have worked with Christer Falgren on a document that attempts to surface issues that would need to be addressed in fully specifying listener support. We have not attempted to specify/solve the issues, just to enumerate issues that would need to be addressed.

The work is captured in the following google doc:

https://docs.google.com/document/d/1gJ2XTO8ERne3tokLMI-FsOCQAmryjeDbS889YPJgcH0/edit

Feel free to comment in the document and or by appending to this issue.

[yannis666]

My preference given all the issues outlined in the document above is to take listeners of of the specification. Implementers would of course be free to provide listeners as they see fit.

[ryangardner]

If listeners are left out of the spec, then any users of the spec who need to use listeners - even for basic use cases - will be required to code directly to the underlying implementation's listeners.

If the spec can come up with a way to define listeners in such a way that it is useful in many/most cases people I suspect that there will be a large number of users who might never need to be concerned with the underlying caching implementation at all.

These issues all have to be addressed by everyone who creates a cache and has event listeners. Is there a lot of variation between how existing cache solutions address these issues?

[yannis666]

Yes, if listeners were not specified in the spec, then "native" code would need to be used. I think in the case of listeners this is not so bad in that this is usually localized, startup code. Here is an exampel of how listeners could be registered using an (experimental) Coherence implementation:

@Test
public void testListener() throws Exception {
    Cache<Integer, String> cache = Caching.getCacheManager().getCache("myCache");
    com.tangosol.net.NamedCache namedCache =
            cache.unwrap(com.tangosol.coherence.jsr107.CoherenceCache.class).getNamedCache();
    com.tangosol.util.MapListener myListener = new com.tangosol.util.MapListener() {
        @Override
        public void entryInserted(com.tangosol.util.MapEvent evt) {
            System.out.println("entryInserted: " + evt);
        }

        @Override
        public void entryUpdated(com.tangosol.util.MapEvent evt) {
            System.out.println("entryUpdated: " + evt);
        }

        @Override
        public void entryDeleted(com.tangosol.util.MapEvent evt) {
            System.out.println("entryDeleted: " + evt);
        }
    };
    namedCache.addMapListener(myListener);
    namedCache.put(1, "a");
    assertEquals("a", namedCache.get(1));
}

[yannis666]

Addressing Ryan's comment on existing cache solutions my example above illustrates some aspects of Coherence's listener implementation.

• Standard listeners implement MapListener
• Standard listeners fire after the causing event and asynchronously.

Above I say standard because Coherence offers many different types of Cache not all of which necessarily behave the same way.

Note that MapListener is quite different to the proposed JSR 107 listener, CacheEntryListener. Also the registration is significantly different; see ObservableMap.

Coherence provides a discussion of listeners here. Coherence also supports listeners that are synchronous and fire only once in the cache. There is a discussion here. Finally similar effects can be obtained using continuous query, documented here

This is an example of one vendor's, Oracle's approach to listeners.

[yannis666]

Closed because subsumed by https://github.com/jsr107/jsr107spec/issues/48

[yannis666]

interceptors shot down

[yannis666]

I am not happy with the final compromise (synchronous listeners in the thread of execution) but am prepared to accept them and am therefore closing the issue