ClusterCacheRef - a different approach

[Richard Emberson <re...@edgedynamics.com>]

I am interested in using Slide as a content store for a distributed
application. Parts of the application are in different appservers.
The appservers all have access to the same central database.
The application parts are ears, one or more per appserver.
Parts of the application can run without other parts. Some parts are
dynamically added/removed.

I've looked at the ClusterCacheRef class and it requires that all Slide
instances are known to all others and that they be static.

A different approach is to use JGroups group membership as the mechanism
for determining which other Slide instances a NotificationListener
should be registered with. (JGroups is a process group implementation).

At a minimum, JGroups allows members to know when other members come and
go and what the current membership list is. This would allow each member
to register with new members. There would be no need for, up front,
knowledge of all members.

Can anyone think of any reason this approach would not work?

Thanks.

Richard


At maximum (and not what I am volunteering to do) one could make the
ExtendedStore cache a JGroup distributed cache - all data
synchronization would be handled by JGroups code.


-- 
This email message is for the sole use of the intended recipient(s) and
may contain confidential information.  Any unauthorized review, use,
disclosure or distribution is prohibited.  If you are not the intended
recipient, please contact the sender by reply email and destroy all
copies of the original message.

---------------------------------------------------------------------
To unsubscribe, e-mail: slide-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: slide-user-help@jakarta.apache.org

Re: ClusterCacheRef - a different approach

[James Mason <ma...@apache.org>]

Richard,
This was one of the options originally considered (the other being JMS).
The current approach was chosen for two reasons:

1) It uses WebDAV

2) It was easy to implement

If you're willing to right the code, I would love to see JGroups used
for notifications. As you say, that would make configuration simpler.
Your "maximum" suggestion would be the ideal, since the other options
all have problems with concurrent locks, but anything would be welcome.

-James

On Thu, 2004-11-11 at 09:55 -0800, Richard Emberson wrote:
> I am interested in using Slide as a content store for a distributed
> application. Parts of the application are in different appservers.
> The appservers all have access to the same central database.
> The application parts are ears, one or more per appserver.
> Parts of the application can run without other parts. Some parts are
> dynamically added/removed.
> 
> I've looked at the ClusterCacheRef class and it requires that all Slide
> instances are known to all others and that they be static.
> 
> A different approach is to use JGroups group membership as the mechanism
> for determining which other Slide instances a NotificationListener
> should be registered with. (JGroups is a process group implementation).
> 
> At a minimum, JGroups allows members to know when other members come and
> go and what the current membership list is. This would allow each member
> to register with new members. There would be no need for, up front,
> knowledge of all members.
> 
> Can anyone think of any reason this approach would not work?
> 
> Thanks.
> 
> Richard
> 
> 
> At maximum (and not what I am volunteering to do) one could make the
> ExtendedStore cache a JGroup distributed cache - all data
> synchronization would be handled by JGroups code.
> 
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: slide-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: slide-user-help@jakarta.apache.org