Can near cache invalidation be made synchronous or is it always asynchronous?

[javafanboy]

I have looked at the documentation for Near Cache and found info about the various invalidation modes but I do not find it spelled out clearly if the invalidations in the local part of the near cache when the distributed tier is updated are synchronous or asynchronous?
To not slow down updates (there can obviously exist MANY front caches) to much I would assume the default at least is asynchronous but I would like this confirmed and also know if there for cases where this would be desirable is possible to make them synchronous?

[aseovic]

This is an interesting one, and if you dig into the code you may get a wrong impression ;-)

NearCache uses SynchronousListener to receive invalidation events, which may lead you to believe that the invalidation is indeed synchronous. However, that's not the case -- all that means is that the events will be processed by the service thread that received them, instead of being queued up to be dispatched by the event dispatcher thread, as the events for regular MapListeners are. This ensures in order delivery of events for a given member, but it doesn't make the event notification itself truly "synchronous" across the cluster.

So to answer your question, no we don't support truly synchronous invalidation (or any other kind of) events, as they would be quite expensive in large clusters, with many listeners involved.

[javafanboy]

Thanks for clearing that up - it it just me who is looking in the wrong place or is the documentation a bit lacking on these kind of quite important "non functional" information?
Is it possible to contribute to the documentation (a quick look at the github code base did not reveal any documentation) or is that only managed by Oracle as it is largely common with thee enterprise edition?

[javafanboy]

I actually have a follow-up question - what happens if the asynchronous update of one of the local caches in a "near cache" fails due to say "out of memory" (OOM) error, Is there a way to detect this if it happens?
We often treat all OOM errors as critical and just terminate the JVM (with a heap dump to debug the problem) but I am thinking if it in our application would be possible to avoid this quite drastic way of handling OOM and in fact I have so far only come up with this one case that I do not know how to possibly recover avoiding the overhead of starting a new VM (that need to warm up its byte code and cache etc)...
Potentially I could stop incoming requests, try free up some heap, request all changes to the cached data from the database since some suitable safe point in time and just invalidate those entries in the local cache and finally restart trafic again - but as mentioned to do this I must have a way to know that there have been an OOM in the Coherence synchronous update thread has happened....

[aseovic]

Sorry, missed this.

If the update fails because of insufficient memory, you will get OOM error. Unfortunately, there is no way for us to detect (or prevent) process running out of memory. Killing and restarting the process when OOM occurs is probably the safest thing to do, and something we recommend (along with the heap dump capture).

That said, you should size-limit the near cache to prevent OOM from happening in the first place, which boils down to figuring out/estimating the average entry size on heap, and deciding how much memory you want to give to your near cache. Unfortunately, you have to specify the limit as the maximum number of entries, as BINARY calculator, which would allow you to limit the amount of memory directly, is not usable with deserialized objects.