How do you troubleshoot stale data issues caused by EclipseLink's shared cache?

Stale-cache symptoms usually show up as a query returning an entity's old values even though the underlying row was clearly updated, most often traced to either a cluster where cache coordination isn't configured, or a database write that bypassed EclipseLink entirely.

1. Check for out-of-band writes - a direct SQL update, a batch job, or a different application writing to the same table won't be reflected in EclipseLink's cache, since the cache only updates in response to changes it commits itself.
2. Check cache coordination in clustered deployments - if the application runs on multiple JVM nodes without cache coordination (RMI/JMS) configured, a commit on one node has no way to invalidate the cached copy sitting on another node.
3. Use the eclipselink.refresh hint for known-volatile queries - forces EclipseLink to bypass the cache and re-read from the database for that specific query, useful for data that's occasionally updated externally.
4. Explicitly evict stale entries when needed - em.getEntityManagerFactory().getCache().evict(Entity.class, id) removes a specific cached entry on demand, useful right after a known out-of-band change.
5. Reconsider whether the entity should be cached at all - for tables frequently modified outside EclipseLink's control, disabling caching for that entity type with @Cache(isolation = CacheIsolationType.ISOLATED) or a very short expiry may be more reliable than trying to keep the cache in sync.

The underlying principle is that EclipseLink's shared cache only knows about changes made through EclipseLink itself (or coordinated from another EclipseLink node); any write path outside that boundary needs an explicit refresh, eviction, or a conscious decision to exclude that data from caching altogether.