Hibernate / EclipseLink Interview questions
How does EclipseLink's shared cache differ from Hibernate's second-level cache?
Both frameworks cache entity instances beyond a single persistence context to avoid redundant database hits, but they differ in default behavior and in how much external configuration is needed to get there.
| EclipseLink shared cache | Hibernate second-level cache |
| Enabled by default for entities, using EclipseLink's own in-memory cache implementation. | Disabled by default; requires enabling and configuring an external cache provider. |
Per-entity control via @Cache (type, size, expiry) built into the provider. | Per-entity control via @Cache/@Cacheable plus the chosen cache provider's own configuration. |
| No separate cache provider dependency required. | Requires a separate cache provider (like Ehcache or Infinispan) as a dependency. |
| Supports cache coordination (RMI/JMS) to invalidate/update peers in a cluster natively. | Cluster-wide invalidation depends on the chosen cache provider's own clustering support. |
The practical upshot is that EclipseLink's cache "just works" out of the box for a single JVM, while Hibernate's requires deliberately wiring in a cache provider before second-level caching does anything at all, though both ultimately offer comparable clustering capability once fully configured.
Is EclipseLink's shared cache enabled by default?
Hibernate's second-level cache requires:
More Related questions...
