Explain the internal working of EclipseLink's cache coordination?

Cache coordination keeps the shared (L2) cache consistent across multiple JVMs in a clustered deployment. Without it, a change committed on one node's shared cache would leave every other node holding a now-stale cached copy of the same entity, since each JVM's shared cache is otherwise entirely independent.

When a transaction commits on one node, EclipseLink broadcasts a change notification over a configured transport, RMI or JMS being the common choices, to every other node participating in coordination. Each receiving node then either invalidates its cached copy of the affected entities (forcing a fresh database read next time they're needed) or applies the change directly to its own cache, depending on the configured coordination mode.

This trades some network overhead and eventual-consistency lag for keeping cache hit rates high across a cluster; the alternative, disabling the shared cache in clustered deployments entirely, avoids staleness but gives up the performance benefit the cache exists to provide in the first place.