You are viewing a plain text version of this content. The canonical link for it is here.
Posted to jcs-users@jakarta.apache.org by Michael Stevens <ms...@etla.org> on 2007/01/02 17:50:20 UTC
IssueRemoveOnPut and back-and-forth removal
Hi.
Another question about clustered caching and IssueRemoveOnPut.
I have a clustered cache setup with two machines A and
B. IssueRemoveOnPut is enabled so that I don't try to replicate
objects, just ensure obsolete versions are removed from the cache.
Machine A has object 1 cached.
Machine B has object 1 cached.
Machine A updates object 1 and calls put() to store the new version.
Machine B receives a remove (from the put), and removes object 1
from the cache.
Later, Machine B tries to access object id 1, finds it is uncached,
loads it from the database, and stores it in the cache by calling
put().
Machine A receives a remove (from the put!), and removes object 1
from the cache.
Repeat endlessly. How can I stop replacing the invalidated cache entry
from issuing another remove?
Michael
---------------------------------------------------------------------
To unsubscribe, e-mail: jcs-users-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jcs-users-help@jakarta.apache.org
Re: IssueRemoveOnPut and back-and-forth removal
Posted by Michael Stevens <ms...@etla.org>.
I'm using the lateral cache.
I'll investigate the filter remove by hashcode stuff, although I'm not
certain if all my objects actually define sensible hashcodes.
Thanks, Michael
Aaron Smuts wrote:
> Are you using the lateral or the remote cache? The
> lateral has a setting called filter remove by hash
> code. This prevents removal if the hashcode is the
> same. This solves your problem.
>
> If you are using the remote cache then you have a
> different situation.
>
> Let's say that B gets an element E from the db and
> then adds it to the cache. It goes to R (the remote
> cache). The remote cache issues a remove to all the
> clients. Clienbt A gets a request for the element E.
> It checks its local cache and doesn't have it. A then
> checks the remote cache. It finds the element and and
> adds it locally. (There is also a setting to add the
> element to A when B adds it to the remote cache).
>
> In extremely high traffic scenarios with low hit and
> high put rates, I set the local memory size to 0 and
> configure the clients of the remote cache to not
> receive updates.
>
> Aaron
>
> --- Michael Stevens <ms...@etla.org> wrote:
>
>> Hi.
>>
>> Another question about clustered caching and
>> IssueRemoveOnPut.
>>
>> I have a clustered cache setup with two machines A
>> and
>> B. IssueRemoveOnPut is enabled so that I don't try
>> to replicate
>> objects, just ensure obsolete versions are removed
>> from the cache.
>>
>> Machine A has object 1 cached.
>> Machine B has object 1 cached.
>>
>> Machine A updates object 1 and calls put() to store
>> the new version.
>>
>> Machine B receives a remove (from the put), and
>> removes object 1
>> from the cache.
>>
>> Later, Machine B tries to access object id 1, finds
>> it is uncached,
>> loads it from the database, and stores it in the
>> cache by calling
>> put().
>>
>> Machine A receives a remove (from the put!), and
>> removes object 1
>> from the cache.
>>
>> Repeat endlessly. How can I stop replacing the
>> invalidated cache entry
>> from issuing another remove?
>>
>> Michael
>>
>>
> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:
>> jcs-users-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail:
>> jcs-users-help@jakarta.apache.org
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jcs-users-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: jcs-users-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: jcs-users-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jcs-users-help@jakarta.apache.org
init cache on cache startup in distributed cache
Posted by Phineas Fung <ph...@ckh.com.hk>.
Hi Aaron,
May I know what is the suggested way to init a cache in a distributed cache
environ?
Now I've server A and B running in lateral TCP mode. During normal running
when both servers are alive, the distributed cache is properly synchronized.
However, when server A is down and restarted, its cache content is clear,
what is the suggested way to load the cache content from server B to
initialize cache in server A?
Thanks alot.
Best Regards,
Phineas Fung
---------------------------------------------------------------------
To unsubscribe, e-mail: jcs-users-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jcs-users-help@jakarta.apache.org
Re: IssueRemoveOnPut and back-and-forth removal
Posted by Aaron Smuts <as...@yahoo.com>.
Are you using the lateral or the remote cache? The
lateral has a setting called filter remove by hash
code. This prevents removal if the hashcode is the
same. This solves your problem.
If you are using the remote cache then you have a
different situation.
Let's say that B gets an element E from the db and
then adds it to the cache. It goes to R (the remote
cache). The remote cache issues a remove to all the
clients. Clienbt A gets a request for the element E.
It checks its local cache and doesn't have it. A then
checks the remote cache. It finds the element and and
adds it locally. (There is also a setting to add the
element to A when B adds it to the remote cache).
In extremely high traffic scenarios with low hit and
high put rates, I set the local memory size to 0 and
configure the clients of the remote cache to not
receive updates.
Aaron
--- Michael Stevens <ms...@etla.org> wrote:
> Hi.
>
> Another question about clustered caching and
> IssueRemoveOnPut.
>
> I have a clustered cache setup with two machines A
> and
> B. IssueRemoveOnPut is enabled so that I don't try
> to replicate
> objects, just ensure obsolete versions are removed
> from the cache.
>
> Machine A has object 1 cached.
> Machine B has object 1 cached.
>
> Machine A updates object 1 and calls put() to store
> the new version.
>
> Machine B receives a remove (from the put), and
> removes object 1
> from the cache.
>
> Later, Machine B tries to access object id 1, finds
> it is uncached,
> loads it from the database, and stores it in the
> cache by calling
> put().
>
> Machine A receives a remove (from the put!), and
> removes object 1
> from the cache.
>
> Repeat endlessly. How can I stop replacing the
> invalidated cache entry
> from issuing another remove?
>
> Michael
>
>
---------------------------------------------------------------------
> To unsubscribe, e-mail:
> jcs-users-unsubscribe@jakarta.apache.org
> For additional commands, e-mail:
> jcs-users-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: jcs-users-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jcs-users-help@jakarta.apache.org