Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » EclipseLink » Cache coordination instructions for Glassfish 3.1 and JMS(How I got a JPA app with caching working on a multihost GF 3.1 cluster)
Cache coordination instructions for Glassfish 3.1 and JMS [message #684984] Thu, 16 June 2011 10:52 Go to next message
J F is currently offline J F
Messages: 242
Registered: July 2009
Senior Member
JPA2 Eclipselink v 2.2 , Glassfish 3.1 clustering and cache-coordination.

The following details the tasks I had to perform to get my app working in a clustered environment with Glassfish and Eclipselink making use of the cache-coordination service of Eclipselink set up via JMS.

In this example I assume that you have followed the getting started type guidelines for setting up a cluster. e.g. http://download.oracle.com/docs/cd/E18930_01/html/821-2432/index.html Chp2 deploying to a cluster, or the High availability Admin Guide http://download.oracle.com/docs/cd/E18930_01/html/821-2426/index.html . My configuration consists of the db and DAS running on a separate box and the instances running on 2 nodes;
Node 1 runs instance1 and instance2 ( i.e. 2 jvms )(
Node 2 runs instance2.
I also have a loadbalancer at the front end which round robbins the application requests ( minimal JAXB/XML over Http to a servlet which uses injection to get hold of the Entity Manager )
I have done NOTHING to my JMS setup, so it is running in Embedded mode with the default clustering set up. This is fine for me in system test mode. If you are following these steps then I assume you have not set up a Local or Remote cluster or an Enhanced cluster etc.. See http://download.oracle.com/docs/cd/E18930_01/html/821-2443/index. The Message Queue 4.5 Technical Overview.
The starting point for Eclipselink JPA cache-coordination docs is http://wiki.eclipse.org/EclipseLink/Examples/JPA/CacheCoordination ( this will give you your persistence.xml settings )

0/ You do not have to use cache-coordination. However if you do not and you are running in a cluster your app will probably fail UNLESS you turn caching off altogether (probable performance hit vs caching). You can do this in the persistence.xml using the eclipselink.cache.shared.default property.

<?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" version="2.0"
xsi:schemaLocation="http://java.sun.com/xml/ns/persistence http://java.sun.com/xml/ns/persistence/persistence_2_0.xsd">

<persistence-unit name="Experiment5jndiPU"
transaction-type="JTA">
<provider>org.eclipse.persistence.jpa.PersistenceProvider</provider>
<jta-data-source>ExperimentDB5Spy</jta-data-source>
<properties>
<property name="eclipselink.cache.shared.default" value="false"/>
</properties>
</persistence-unit>

</persistence>

1/ If you do want to use cache-coordination - You must annotate the entity classes or provide a Session customizer to switch on cache-coorindation per entity.

For example using annotations;

import org.eclipse.persistence.annotations.Cache;
import org.eclipse.persistence.annotations.CacheCoordinationType;

@Entity
@Cache(coordinationType=CacheCoordinationType.SEND_NEW_OBJECTS_WITH_CHANGES)
public class ParentEntity implements IParentEntity {

See http://wiki.eclipse.org/EclipseLink/UserGuide/JPA/Basic_JPA_Development/Caching/Cache_Annotation

2/ Your persistence.xml must describe the type of cache-coordination to use;

<?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" version="2.0"
xsi:schemaLocation="http://java.sun.com/xml/ns/persistence http://java.sun.com/xml/ns/persistence/persistence_2_0.xsd">

<persistence-unit name="Experiment5jndiPU"
transaction-type="JTA">
<provider>org.eclipse.persistence.jpa.PersistenceProvider</provider>
<jta-data-source>ExperimentDB5Spy</jta-data-source>
<properties>
<property name="eclipselink.cache.coordination.protocol" value="jms" />
<property name="eclipselink.cache.coordination.jms.topic" value="Experiment5jpacc" />
<property name="eclipselink.cache.coordination.jms.factory" value="Experiment5jpacc_pool" />
</properties>
</persistence-unit>
</persistence>

3/ You must add the resouces to your cluster. The following is a file which can be used with the asadmin add-resources command which is explicit about what is being done. N.B. You must target these resources at your cluster using the asadmin command ...
asadmin add-resources target cluster1 filename.xml

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE resources PUBLIC "-//GlassFish.org//DTD GlassFish Application Server 3.1 Resource Definitions //EN" "http://glassfish.org/dtds/glassfish-resources_1_5.dtd">
<resources>
<admin-object-resource res-adapter="jmsra" res-type="javax.jms.Topic" jndi-name="Experiment5jpacc">
<property description="null" name="Name" value="Experiment5jpacc"></property>
</admin-object-resource>
<connector-connection-pool name="Experiment5jpacc_pool" resource-adapter-name="jmsra" connection-definition-name="javax.jms.TopicConnectionFactory">
<property name="useSharedSubscriptionInClusteredContainer" value="false"></property>
</connector-connection-pool>
<connector-resource pool-name="Experiment5jpacc_pool" jndi-name="Experiment5jpacc_pool"></connector-resource>
</resources>

Note the following. I have NOT set anything to do with the transaction support of the Connection Factory. I have not set up a ClientID on the factory or anywhere else as this does not seem to be appropriate. It would seem that Eclipselink does not create a durable subscription ( why would it its for in memory caching?... ) but does want messages to be delivered to all subscribers that are active. My brief reading of http://download.oracle.com/docs/cd/E19575-01/821-0027/gjzpg/index.html GlassFish Message Queue 4.4 Administration Guide, About Shared Topic Subscriptions for Clustered Containers suggests that we should be turning 'useSharedSubscriptionInClusteredContainer' to off ( its is on by default ) because Eclipselink would presumably want all connections to get the change messages. There is more on this at http://java.net/jira/browse/GLASSFISH-6580

4/ After a couple of hicups getting started this worked with my Derby DB. Using a Spying JDBC driver I logged the SQL going to Derby and found that using the CacheCoordinationType.SEND_NEW_OBJECTS_WITH_CHANGES setting reduced the SQL traffic to the minimum.

When I get time I hope to package up the test sources. I hope someone like James will corrct any faults I have put in.


Re: Cache coordination instructions for Glassfish 3.1 and JMS [message #685878 is a reply to message #684984] Mon, 20 June 2011 09:53 Go to previous message
James Sutherland is currently offline James Sutherland
Messages: 1939
Registered: July 2009
Location: Ottawa, Canada
Senior Member

Thank you for working on this example.

Feel free to add a Glassfish section to the examples wiki,

http://wiki.eclipse.org/EclipseLink/Examples/JPA/CacheCoordination


James : Wiki : Book : Blog : Twitter
Previous Topic:@Cache annotations set for the entire Peristence Unit
Next Topic:Eclipselink version for JBoss EAP 5.1.0
Goto Forum:
  


Current Time: Thu Apr 17 00:10:36 EDT 2014

Powered by FUDForum. Page generated in 0.05940 seconds