EclipseLink/UserGuide/JPA/Basic JPA Development/Caching/DatabaseEvents
|Mailing List • Forums • IRC • mattermost|
|Open • Help Wanted • Bug Day|
Database Event Driven Cache Invalidation
Some databases and database products allow events to be raised from the database when rows are updated or deleted in the database. The Oracle database supports Database Change Notification (DCN, QCN) EclipseLink supports an API to allow the database to notify EclipseLink of database changes, so the changed objects can be invalidated in the EclipseLink shared cache.
EclipseLink provides cache coordination in a clustered environment to ensure the servers caches are is sync.
There are also many other solutions to caching in a clustered environment, including:
- Disable the shared cache (through setting
- Only cache read-only objects.
- Set a cache invalidation timeout to reduce stale data.
- Use refreshing on objects/queries when fresh data is required.
- Use optimistic locking to ensure write consistency (writes on stale data will fail, and will automatically invalidate the cache).
- Use a distributed cache (such as Oracle TopLink Grid's integration of EclipseLink with Oracle Coherence).
- Use database events to invalidate changed data in the cache (such as EclipseLink's support for Oracle DCN/QCN).
Cache coordination enables a set of persistence units deployed to different servers in the cluster (or on the same server) to synchronize their changes. Cache coordination works by each persistence unit on each server in the cluster being able to broadcast notification of transactional object changes to the other persistence units in the cluster. EclipseLink supports cache coordination over RMI and JMS. The cache coordination framework is also extensible so other options could be developed.
Cache coordination works by broadcasting changes for each transaction to the other servers in the cluster. Each other server will receive the change notification, and either invalidate the changed objects in their cache, or update the cached objects state with the changes. Cache coordination occurs after the database commit, so only committed changes are broadcast.
Cache coordination greatly reduces to chance of an application getting stale data, but does not eliminate the possibility. Optimistic locking should still be used to ensure data integrity. Even in a single server application stale data is still possible within a persistence context unless pessimistic locking is used. Optimistic (or pessimistic) locking is always required to ensure data integrity in any multi-user system.
Configuring Cache Coordination
Cache coordination is configured using persistence unit properties. The following cache coordination properties are supported:
EclipseLink persistence.xml cache coordination JMS example
<?xml version="1.0" encoding="UTF-8"?> <persistence xmlns="http://java.sun.com/xml/ns/persistence" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://java.sun.com/xml/ns/persistence persistence_2_0.xsd" version="2.0"> <persistence-unit name="acme" transaction-type="RESOURCE_LOCAL"> <provider>org.eclipse.persistence.jpa.PersistenceProvider</provider> <exclude-unlisted-classes>false</exclude-unlisted-classes> <properties> <property name="eclipselink.cache.coordination.protocol" value="jms"/> <property name="eclipselink.cache.coordination.jms.topic" value="jms/ACMETopic"/> <property name="eclipselink.cache.coordination.jms.factory" value="jms/ACMETopicConnectionFactory"/> </properties> </persistence-unit> </persistence>