[eclipselink-users] Cache Coordination via JMS

[Christopher.Mathrusse@xxxxxxxxxx]

Our application is running within a GlassFish
v2 cluster that utilizes a REMOTE JMS Cluster. There are only 2 server
instances within the cluster at this time. I've provided EclipseLink with
an implementation of SessionCustomizer so I can utilize a JMS Topic to
perform my Cache Coordination. This proved to be a challenge as GlassFish
attempts to share the subscription to the topic when deployed in a cluster.
Per one of the Sun engineers:

The behavior is that we are "sharing"
the consumer across the cluster.
This behavior is only turned on for
a glassfish cluster.

What does share mean ???

For durables what it means is:
if you create two durables with the
same name and same clientID on different servers ... they will be considered
a "single" durable.
e.g.:
You send 10 messages to topic foo
[and create two subscribers with a clientID of cid1 and a durable name
of dname]
[gf instance 1: cid1, dname on foo]
gets 5 messages
[gf instance 2: cid1, dname on foo]
- gets 5 messages

For non-durable subscribers:
If you create two subscribers on
the same topic with the same clientID, they will share messages (same as
the above durables case)

After reading through this I figured
out that I don't want the subscription shared. I needed to turn off sharing
to prevent the messages from being distributed over the 2 servers. This
was a bit of a challenge but I managed to do this by creating a custom
implementation of an InitialContextFactory, binding the Topic Factory into
the Spring container and applying some advice to the connection factory
to ensure that the connection does not share subscriptions. This works
well in my local GlassFish clustered environment. But when I gave it to
the Infrastructure Group to deploy in their test environment their GlassFish
instances seemed to have issues. They contacted a Sun consultant that helped
them configure the environment and he recommended that we not use JMS for
EclipseLink Cache Coordination but rather JGroups. I read over their documentation
and this is a completely proprietary messaging implementation using IP
Multicast. While this looks like a good library, this would be a custom
implementation that would not interface well with EclipseLink and would
require me to do a considerable amount of work.

Can anyone speak to this? Personally,
I find that the JMS implementation of Cache Coordination seems very simple
and easy to use. I don't see where there would be any disadvantages to
using it nor do I see any reason why I should utilize JGroups.

Thanks for the help...

Chris Mathrusse
christopher.mathrusse@xxxxxxxxxx
Sybase, Inc