--- On Tue, 8/11/09, Jeffrey Kesselman <jef...@gmail.com> wrote:
> From: Jeffrey Kesselman <jef...@gmail.com> > Subject: Re: Some preliminary JCS questions > To: "JCS Users List" <jcs-users@jakarta.apache.org> > Date: Tuesday, August 11, 2009, 7:22 PM > Thanks Aaron, > > One or two more questions? > > On Tue, Aug 11, 2009 at 10:47 AM, Aaron Smuts <asm...@yahoo.com> > wrote: > > > > > > > Client can register listeners or not. You want > to register listeners if > > you want to receive notification about changes. > You need to do this if you > > store volitile data on the clients. Otherwise, > don't. It can create a lot > > of chatter if there are lots of puts. > > > A listener is a local callback when an item of data is > changed by beign > pushed from A (in the example)? > Yes. The Remote Cache Client can register a listener. The remote server will broadcast puts and removes to the listeners. > > > > > > 2. Remote servers do not replicate on > startup. They will fetch data on > > demand. > > > So do remote servers lose all state when they shut down and > start "fresh"? > if not how do they know if a data item is stale (been > updated at the server > end) > They can't know if it is stale. If your data changes a lot, youl'' want the primary to come up empty. If you are using the disk cache, you can configure it to delete all stored data on startup. The data will still be retrievable. The primary will try to get it from the failover. If it finds it, the primary will store it locally and return it to the client. > This app is a LOT of data that needs to be available in a > timely fashion. I > really need to eb abkle to "preload" the remote cache... > If the failover has the data, it will be timely. If the data doesn't change much, then if you use the indexed disk cache or the jdbc disk cache, the data will be on the primary. > > > > JK > --------------------------------------------------------------------- To unsubscribe, e-mail: jcs-users-unsubscr...@jakarta.apache.org For additional commands, e-mail: jcs-users-h...@jakarta.apache.org
