Hello,
in conjunction with your remove-and-putcache policy, you can accomplish "broadcast removes" by setting the following in lateral cache: # Setting Receive equal to false means the cache operates in send-only mode jcs.auxiliary.LTCP.attributes.Receive=true # Setting AllowGet equal to false would cause the auxiliary cache to return null from any get request jcs.auxiliary.LTCP.attributes.AllowGet=false jcs.auxiliary.LTCP.attributes.IssueRemoveOnPut=true jcs.auxiliary.LTCP.attributes.FilterRemoveByHashCode=false Furthermore to explicitly avoid object serialization, mark the elements to not be laterally distributable: jcs.region.MyCacheRegion.elementattributes.IsLateral=false These settings work for me... Hans Liebenberg <[EMAIL PROTECTED]> hat am 24. November 2008 um 10:34 geschrieben: > Hi, > > We currently use JCS on a single instance using a basic memory cache. > This has worked perfectly for us, but now we have the need for our > software to reside in a clustered env. > What I essentially want is a TCP Lateral cache where each node's cache > acts independently of one another using LRUMemory cache, except they > should broadcast "removes" so that the other nodes can clear the > specified key in the region. > No need for object serialization across the network, i.e no gets or puts > need to be broadcasted. > > Our code always does a remove before a put, so a simple remove broadcast > should suffice. > > I have experimented with various settings but can't seem to get it right > so now I am thinking its not actually possible. > > I was hoping setting AllowGet=false and Receive=false would do the > trick, but that seems to block removes too. > > I also experimented with the IssueRemoveOnPut but then I get the > expected back and forth removals between the nodes, i.e only one node > can have the object cached at anyone time. I know I am then meant to set > FilterRemoveByHashCode to true, but it won't be easy generating sensible > hashcodes. > > So is there any other way to achieve a "broadcast removes only" type > config? Or any other recommendations? > > Thanks > Hans > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > -- with best regards, Thorben Betten
