Summary | Download
ShiftOne Java Object JMS Clustering
JMS based clustering deserves a bit more explanation. For non-J2EE applications, it is fairly simple. The example below will configure a factory to create a JMS cluster cache that will sit in front of a LRU cache in a non-J2EE environment.
In a J2EE environment, things become more complex. Take a look at the following article Why are JMS APIs restricted in J2EE and how to workaround it . The summary is, in some J2EE containers, it is not possible for the cache to register itself as a MessageListener for a topic it obtained from the local JNDI. The reason is the objects returned by the container will be wrapped with proxies that disable the Session.setMessageListener method. It does this to attempt to enforce the J2EE "create thee no theads" rule.
Keep in mind, that not all application servers may be as strict on this point as WebSphere. If you are lucky, and are using a different application server, you may be able to use the configuration mentioned above.
In some environments, this problem can be avoided by registering for messages with the broker directly. This is possible if the message broker is registered in a JNDI server outside the container. Some message brokers ( Tibco EMS) come with built in JNDI servers, other do not but can be installed in "Sun's File System Context Provider" ( SwiftMQ).
You can configure JOCache to use the external JNDI and broker for both in and outbound messages, but it is really only necessary for inbound messages. You may want to send outbound messages to a topic connection obtained from the container, and receive from one obtained from the broker. This allows outbound messages to be transacted, which is useful if you are caching transactional data (like data from a database).
The below configuration shows how a JMS Cluster factory can be configured to send to one topic and receive from another topic. Obviously, if these topics are not logically the same, clustering will not work.
|ShiftOne Object Cache 2.1
© Jeff Drost