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

(New page: ==Overview== 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 probl...)

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

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

−

* disabling the shared cache

+

* disable the shared cache

−

* only caching read-only objects

+

* only cache read-only objects

* set a cache invalidation timeout

* set a cache invalidation timeout

−

* refreshing

+

* use refreshing on objects/queries when fresh data is required

−

* using a distributed cache

+

* use optimistic locking (writes on stale data will fail, and will automatically invalidate the cache)

−

* using cache coordination (synchronizing the caching)

+

* using a distributed cache (such as Oracle TopLink Grid with Oracle Coherence)

+

* using database events to invalidate changed data

+

* using cache coordination (synchronizing the caches, as discussed in this example)

This example gives an overview of the <i>cache coordination</i> option.

This example gives an overview of the <i>cache coordination</i> option.

EclipseLink provides a cache coordination feature that enables a set of EclipseLink sessions to synchronize their changes in a distributed network such as an application server cluster. Cache coordination works by each EclipseLink session (ServerSession/persistence unit) on each server in the cluster being able to broadcast notification of transactional object changes to the other EclipseLink sessions in the cluster. EclipseLink supports cache coordination over RMI and JMS. The cache coordination framework is also extensible so other options could be developed.

EclipseLink provides a cache coordination feature that enables a set of EclipseLink sessions to synchronize their changes in a distributed network such as an application server cluster. Cache coordination works by each EclipseLink session (ServerSession/persistence unit) on each server in the cluster being able to broadcast notification of transactional object changes to the other EclipseLink sessions in the cluster. EclipseLink supports cache coordination over RMI and JMS. The cache coordination framework is also extensible so other options could be developed.

+

+

JGroups is not currently supported, to request JGroups support vote for,

+

https://bugs.eclipse.org/bugs/show_bug.cgi?id=282074

This example demonstrates enabling cache coordination using JMS or RMI for a JEE EJB 3.0 SessionBean application using JPA deployed to an Oracle Weblogic cluster. The example could be ported to other JEE application servers or environments. EclipseLink supports cache coordination in any Java environment, including Java SE, or Tomcat.

This example demonstrates enabling cache coordination using JMS or RMI for a JEE EJB 3.0 SessionBean application using JPA deployed to an Oracle Weblogic cluster. The example could be ported to other JEE application servers or environments. EclipseLink supports cache coordination in any Java environment, including Java SE, or Tomcat.

+

+

If you encounter any issues in running this example, or are running in another app server or version please discuss,

+

[[Talk:EclipseLink/Examples/JPA/CacheCoordination|here]]

+

+

If you wish to port this example to another application server, or provide a different config or fix, please submit your changes to the [https://bugs.eclipse.org/bugs/show_bug.cgi?id=326343 bug#326343].

==Prerequisites==

==Prerequisites==

The following software is required to run this example:

The following software is required to run this example:

−

* Oracle Weblogic Server (10.3.4 was used, but any WLS version supporting EJB 3 should work, or any JEE application server with some work) - download link

+

* Oracle Weblogic Server (10.3.3 was used, but any WLS version supporting EJB 3 should work, or any JEE application server with some work) - [http://www.oracle.com/technetwork/middleware/downloads/index-087510.html download link]

−

* ant (1.7 was used, but other versions should also work) - download link

+

* ant (1.7 was used, but other versions should also work) - [http://ant.apache.org/bindownload.cgi download link]

−

* Oracle database (or any other client/server database (embedded database will not work as cannot be accessed from all machines))

+

* Oracle database (or any other client/server database (embedded database will not work as cannot be accessed from all machines)) - [http://www.oracle.com/technetwork/database/enterprise-edition/downloads/index.html download link]

−

* EclipseLink (WLS 10.3.4 includes EclipseLink 2.1, a 2.2 build or any >= 1.2 version could be used) - download link

+

* EclipseLink (WLS 10.3.3 includes EclipseLink 2.0, 2.1, a 2.2 build or any >= 1.2 version could be used) - [http://www.eclipse.org/eclipselink/downloads/ download link]

There are several ways to configure cache coordination, and the settings required differ depending on the environment and EclipseLink version. The example source code provides a complete configuration, this section is only provided as a reference. The example defaults to using JMS, and RMI persistence.xml file (persistence-wls-rmi.xml) is also provided as well as an non-clustered RMI build file (build-wls-servers.xml). To run these examples just rename the files.

+

+

EclipseLink supports cache coordination using either JMS, RMI or RMI-IIOP. A custom TransportManager could also be implemented to support another protocol, such as JGroups.

+

+

Cache coordination 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.

+

+

===RMI===

+

To enable cache coordination the minimal amount of configuration required is to set the protocol,

In EclipseLink 2.2 in a WebLogic cluster this is all that is required as JNDI is replicated, each server will be able to look-up each others listener. Previous to EclipseLink 2.2 a URL was still required, in a cluster any URL in the cluster could be given, or localhost.

+

+

If running outside of a cluster, or if JNDI is not replicated, then each server must provide its URL. This could be done through the persistence.xml, but would require a different persistence.xml (thus jar/ear) per server, which is normally not desired. Another option is to set the URL as a System property to the WebLogic start script (or other application server). A SessionCustomizer could also be used to set the URL in code.

Revision as of 10:40, 24 April 2012

Contents

Overview

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 clustered 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 database events to invalidate changed data

using cache coordination (synchronizing the caches, as discussed in this example)

This example gives an overview of the cache coordination option.

EclipseLink provides a cache coordination feature that enables a set of EclipseLink sessions to synchronize their changes in a distributed network such as an application server cluster. Cache coordination works by each EclipseLink session (ServerSession/persistence unit) on each server in the cluster being able to broadcast notification of transactional object changes to the other EclipseLink sessions in the cluster. EclipseLink supports cache coordination over RMI and JMS. The cache coordination framework is also extensible so other options could be developed.

This example demonstrates enabling cache coordination using JMS or RMI for a JEE EJB 3.0 SessionBean application using JPA deployed to an Oracle Weblogic cluster. The example could be ported to other JEE application servers or environments. EclipseLink supports cache coordination in any Java environment, including Java SE, or Tomcat.

If you encounter any issues in running this example, or are running in another app server or version please discuss,
here

If you wish to port this example to another application server, or provide a different config or fix, please submit your changes to the bug#326343.

Prerequisites

The following software is required to run this example:

Oracle Weblogic Server (10.3.3 was used, but any WLS version supporting EJB 3 should work, or any JEE application server with some work) - download link

ant (1.7 was used, but other versions should also work) - download link

Oracle database (or any other client/server database (embedded database will not work as cannot be accessed from all machines)) - download link

EclipseLink (WLS 10.3.3 includes EclipseLink 2.0, 2.1, a 2.2 build or any >= 1.2 version could be used) - download link

Configuring the example

There are several ways to configure cache coordination, and the settings required differ depending on the environment and EclipseLink version. The example source code provides a complete configuration, this section is only provided as a reference. The example defaults to using JMS, and RMI persistence.xml file (persistence-wls-rmi.xml) is also provided as well as an non-clustered RMI build file (build-wls-servers.xml). To run these examples just rename the files.

EclipseLink supports cache coordination using either JMS, RMI or RMI-IIOP. A custom TransportManager could also be implemented to support another protocol, such as JGroups.

Cache coordination 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.

RMI

To enable cache coordination the minimal amount of configuration required is to set the protocol,

<propertyname="eclipselink.cache.coordination.protocol"value="rmi"/>

In EclipseLink 2.2 in a WebLogic cluster this is all that is required as JNDI is replicated, each server will be able to look-up each others listener. Previous to EclipseLink 2.2 a URL was still required, in a cluster any URL in the cluster could be given, or localhost.

If running outside of a cluster, or if JNDI is not replicated, then each server must provide its URL. This could be done through the persistence.xml, but would require a different persistence.xml (thus jar/ear) per server, which is normally not desired. Another option is to set the URL as a System property to the WebLogic start script (or other application server). A SessionCustomizer could also be used to set the URL in code.

For RMI cache coordination the broadcast can be configured to be either asynchronous or synchronous. Asynchronous is the default,
synchronous can be used to ensure that all of the servers are updated before the request returns.