jakarta-jcs-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Niall Gallagher <ni...@switchfire.com>
Subject Re: Remote Cache - Understanding remove method call propagation?
Date Fri, 29 Aug 2008 14:43:05 GMT
Hi Simon,

Answer: (3)
Remove events are propagated to the remote server (which in turn
propagates them to other clients) even if the server which initiated the
remove for that key didn't actually have the object stored against the
key in its own local memory at the time. So basically a client which
does not actually have an object in its own memory, can remove such
objects from other clients' memories as long as it has the key.

This behaviour is configurable I think, but I'm not sure exactly which
setting enables it. We rely on this behaviour in our company so I know
it works. Aaron is the expert on all things JCS so he might jump in to
confirm/deny this. Anyway- you should test this in your own environment.
FYI here's our remote server settings...

jcs.auxiliary.remotecache=org.apache.jcs.auxiliary.remote.RemoteCacheFactory
jcs.auxiliary.remotecache.attributes=org.apache.jcs.auxiliary.remote.RemoteCacheAttributes
jcs.auxiliary.remotecache.attributes.FailoverServers=ip.ip.ip.ip:port
jcs.auxiliary.remotecache.attributes.GetOnly=false
jcs.auxiliary.remotecache.attributes.Receive=true
jcs.auxiliary.remotecache.attributes.RemoveUponRemotePut=true

Best regards,

Niall

On Fri, 2008-08-29 at 15:05 +0100, Horton Simon wrote:

> Hi JCS Gurus,
> 
> I have two tomcat servers, server A and server B both running their own
> local JCS cache. Each local JCS cache is connected to the same Remote
> auxiliary cache (two remote caches operating in a cluster).
> 
> So, normal remote cache operation is along the lines of: If server A
> puts an object in its local cache, with key 1, the object will propagate
> to the remote cache, so if server B tries to get the object with key 1
> from its local cache, it will not find it, then it tries the remote
> cache for key 1 where it finds the object in the remote cache, so return
> this, storing it in server B's local cache. 
> 
> How about this...
> If server A puts an object in its local cache, with key 1, the object
> will propagate to the remote cache. If server B does not have key 1 in
> its local cache, but calls the remove method for key 1 on its local
> cache.....
> 
> What happens?
> (1) Does the server B local JCS remove for key 1 do nothing because it
> is not in the server B local cache.
> 
> (2) Does the server B local JCS remove propagate to the remote cache
> server, but the object for key 1 remains in the server A local cache.
> 
> (3) Does the server B local JCS remove propagate to the remote cache
> server, and the remove propagates to the server A local cache as well.
> So, key 1 does not exist in any cache the next time get is called.
> 
> I am after the functionality in (3) above, is this possible?
> Below is some of my cache config file snippets in case this is helpful.
> 
> Remote Cache Config Snippet
> ###########################
> jcs.auxiliary.RCluster1=org.apache.jcs.auxiliary.remote.RemoteCacheFacto
> ry
> jcs.auxiliary.RCluster1.attributes=org.apache.jcs.auxiliary.remote.Remot
> eCacheAttributes
> jcs.auxiliary.RCluster1.attributes.RemoteTypeName=CLUSTER
> jcs.auxiliary.RCluster1.attributes.RemoveUponRemotePut=true
> jcs.auxiliary.RCluster1.attributes.ClusterServers=localhost:1101,1103
> jcs.auxiliary.RCluster1.attributes.GetOnly=false
> 
> Local Cache Config Snippet
> ###########################
> # - Remote RMI Cache set up to failover
> jcs.auxiliary.RFailover=org.apache.jcs.auxiliary.remote.RemoteCacheFacto
> ry
> jcs.auxiliary.RFailover.attributes=org.apache.jcs.auxiliary.remote.Remot
> eCacheAttributes
> jcs.auxiliary.RFailover.attributes.FailoverServers=localhost:localhost:1
> 101, localhost:1103
> #jcs.auxiliary.RC.attributes.RemoveUponRemotePut=true
> jcs.auxiliary.RFailover.attributes.RemoveUponRemotePut=true
> jcs.auxiliary.RFailover.attributes.GetOnly=false
> 
> 
> Thanks
> Simon 
> 
> This message and any files transmitted with it are confidential and intended solely for
the use of the individual or entity to whom they are addressed. If you have received this
message in error please delete it and any files transmitted with it, after notifying postmaster@uk.mizuho-sc.com

> Any opinions expressed in this message may be those of the author and not necessarily
those of the company. The company accepts no responsibility for the accuracy or completeness
of any information contained herein. This message is not intended to create legal relations
between the company and the recipient. 
> Recipients should please note that messages sent via the Internet may be intercepted
and that caution should therefore be exercised before dispatching to the company any confidential
or sensitive information. 
> Mizuho International plc Bracken House, One Friday Street, London EC4M 9JA. TEL. 020
72361090. Wholly owned subsidiary of Mizuho Securities Co., Ltd. Member of Mizuho Financial
Group. Authorised and regulated by the Financial Services Authority. Member of the London
Stock Exchange. 
> 
> Registered in England No. 1203696. Registered office as above.
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jcs-users-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: jcs-users-help@jakarta.apache.org




Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message