The following is how to get EclipseLink to perform L2 Cache Coordination when the application is deployed in a Glassfish 3.1 cluster. The instructions show how to get cache coordination to work using JMS.

Persistence Unit

The following lines are added to the persistence.xml, describing that the cache coordination should use JMS and the JMS connection factory and topic to use.

 <property name="eclipselink.cache.coordination.protocol" value="jms" />
 <property name="eclipselink.cache.coordination.jms.topic" value="jms/bluefire-cache-coord" />
 <property name="eclipselink.cache.coordination.jms.factory" value="jms/bluefire-cache-factory" />


In the proof of concept the embedded JMS server was use and all the resources were targeted to the cluster.

JMS Physical Destination

In the JMS Physical Destination tab of the cluster, create a physical topic destination.

JMS Connection Pool

When defining the JMS pool that this connection factory should use remember not to specify the Transaction Support. Providing a value of Local causes errors when enlisting in the XA transaction of EclipseLink.

Also provide the Additional Property ClientId with any string value, failing to do so causes errors.

JMS Connection Factory

Create the JMS Connection Factory with the JNDI name specified in the persistence.xml. Link the connection factory to the connection pool.

JMS Topic

Create the JMS topic destination with the JNDI name specified in the persistence.xml.

Link the topic to the physical destination created in the first step. If this was not originally done, then create an attribute Name with the value of the physical destination name.

Next Steps…

The next step is to get locking enabled within EclipseLink because client updates are overwriting each other causing inconsistent data. It also seems that when two clients make changes simultaneously that the cache coordinator is not syncing the changes but this needs more investigation.