Skip to main content
Jump to: navigation, search

Difference between revisions of "EclipseLink/Examples/JPA/DCN"

(Configuring the example)
(Running the example)
Line 52: Line 52:
# Build the application
# Build the application
## Run "ant"
## Run "ant"
## this will compile the example code and build the example jar
## this will compile the example code
# Run the example
# Run the example
## Run "ant example"
## Run "ant example"

Revision as of 11:30, 24 April 2012


EclipseLink supports a shared (L2) object cache that avoids database access for objects and their relationships. This cache is enabled by default which is normally not a problem, unless the database is modified directly by other applications, or by the same application on other servers in a clustered environment.

There are many solutions to caching in a shared environment, including:

  • disable the shared cache
  • only cache read-only objects
  • set a cache invalidation timeout
  • use refreshing on objects/queries when fresh data is required
  • use optimistic locking (writes on stale data will fail, and will automatically invalidate the cache)
  • using a distributed cache (such as Oracle TopLink Grid with Oracle Coherence)
  • using cache coordination
  • using database events to invalidate changed data

This example gives an overview of the database events option.

EclipseLink 2.4 adds support for a DatabaseEventListener to receive database events. EclipseLink provides an OracleChangeNotificationListener to integrate with Oracle's Database Event Notification support (also known as Query Change Notification). The Oracle database added this support in the 10.2 release, but did not fully enable the JDBC support for it until the 11.2 release. The OracleChangeNotificationListener uses Oracle's DCN support to listen to database row changes and invalidate the cache for the objects that are changed on the database. This allows for caching to be used in JPA, even if other applications, even non-Java applications are accessing and updating the same database. This can also be used as an alternative to cache coordination in a cluster.

Integrated support for other databases is not currently provided. If another database supports an event mechanism, or allows triggers to raise events, then it is possible to implement your own DatabaseEventListener to perform cache invalidation. In previous versions of the Oracle database it is possible to perform cache invalidation through triggers and Oracle AQ.

This example demonstrates enabling database event driven cache invalidation using Oracle DCN with the Oracle 11.2 database. The example runs in Java SE, but any other Java EE or EclipseLink supported environment should also work.

If you encounter any issues in running this example, please discuss, here


The following software is required to run this example:

Configuring the example

Database events can be configured using persistence unit properties (in your persistence.xml). It can also be configured in code using a SessionCustomizer, or using System properties (which match the persistence unit properties). This example will use persistence unit properties.

<property name="eclipselink.cache.database-event-listener" value="" />

The database user must have the CHANGE NOTIFICATION privilege granted on the database.


Running the example

  1. Install Oracle database (or use existing database, ensure the database)
  2. Configure paths in <example>/build.xml (JDBC_LIB, JPA_LIB, ECLIPSELINK_LIB)
  3. Configure database URL and user/password in persistence.xml in <example>src/meta-inf/
  4. Install ant (or uses existing ant install)
  5. Build the application
    1. Run "ant"
    2. this will compile the example code
  6. Run the example
    1. Run "ant example"
    2. This should give the following output.
Buildfile: build.xml




Back to the top