Skip Headers
Oracle® Fusion Middleware Integration Guide for Oracle TopLink with Coherence Gird
11g Release 1 (11.1.1)

Part Number E16596-01
Go to Documentation Home
Go to Book List
Book List
Go to Table of Contents
Go to Master Index
Master Index
Go to Feedback page
Contact Us

Go to previous page
Go to next page
View PDF

Understanding the TopLink Grid Integration

TopLink Grid integrates the TopLink JPA implementation (EclipseLink) with Oracle Coherence and provides two development approaches:

When integrating JPA applications with the Coherence Data Grid, you should be aware of potential benefits and restrictions. You must understand how the grid works and how it relates to your JPA configurations in order to realize the full potential.

This section includes information on the following configuration options:

Entity Caching

By default, EclipseLink provides an EntityManagerFactory managed shared Entity cache. This shared cache improves performance for multi-threaded and Java EE server hosted applications running in a single JVM.

With TopLink Grid, you can replace the default EclipseLink Shared (L2) cache with Coherence. This provides support for very large shared grid caches that span cluster nodes, and removes the need for additional configuration to ensure individual shared caches are coordinated. By configuring an Entity as Grid cached in Coherence, all EntityManager.find() calls for that Entity will result in a get on the associated Coherence cache. If Coherence doesn't contain the object the database is queried.

See "Grid Cache" for more information.

Reading and Querying

In addition to Grid cache configuration, you can configure TopLink Grid to direct read queries to Coherence. By configuring a TopLink JPA CacheLoader, even when there is no cache hit, the object can be read from the database and then placed in the cache, thereby making it available for subsequent queries. Coherence's ability to manage very large numbers of objects increases the likelihood of a cache hit as reads in one cluster member become immediately available to others.

While using Coherence to spread an Entity Grid cache across the grid is useful, support for non-primary key queries is especially beneficial. When you configure an Entity as "Grid Read" all reads are directed to Coherence. JPQL queries are automatically translated into Coherence filters and objects that match the filter are retrieved from the grid. Coherence executes all filters in parallel on each member of a cluster. This results in significantly faster processing for a query, compared to if all the objects resided in a single member.

Because filters only apply to objects in the Coherence cache, the configuration of a CacheStore or CacheLoader has no impact on ad-hoc query processing. By default, with this configuration queries are not executed against the database. However, you can override this behavior and with query hints by using the oracle.eclipselink.coherence.integrated.querying.IgnoreDefaultRedirector class as shown in the following example:

query.setHint(QueryHints.QUERY_REDIRECTOR, new IgnoreDefaultRedirector());

This directs the query to the database instead of the Coherence cache.

For complete information on using EclipseLink JPA query hints, refer to the EclipseLink documentation.


Another key configuration option is specifying how to write Entities to the database. You can configure EclipseLink to:

  • Directly write Entities to the database, then put them in Coherence (so that it reflects the database state)


  • Put entities into Coherence, then have Coherence write to the database using a CacheStore.

The CacheStore method supports the Coherence write-behind feature to enable asynchronous database writes. By using this applications do not have to wait for the database to return in order to proceed.

However, this configuration contains some restrictions, such as the inability to use JTA integration or other EclipseLink performance features (including batch writing, parameter binding, stored procedures, and statement ordering).