The way it's *supposed* to work is you only get notifications for changes that occur within the collection you specify. I can't recall actually testing that case, though. Again, I think this part relies on the notification mechanism to determine which events are relevant, so the documentation Daniel mentioned might have clues.
-James On Wed, 2004-12-08 at 10:24 -0800, Warwick Burrows wrote: > This is exactly what I needed James. Thanks! > > > They should be asynchronous. Daniel Florey wrote the > > notification mechanism, so he can confirm, but I'm pretty > > sure on this. > > Daniel, can you confirm that notifications are asynchronous? Or is there a > write-up on the notifications that I can look at? > > And I have another question on the cluster cache :-) There is a "base-uri" > parameter that is specified in the configuration. If this is set to "/files" > will it pick up all changes to objects under /files? For example when a file > is checked out/in with a new revision will it also notify other slide > servers of /history path updates that stem from the change even though > /history isn't specifically configured as the base-uri? > > Thanks, > Warwick > > > > -----Original Message----- > > From: James Mason [mailto:[EMAIL PROTECTED] > > Sent: Tuesday, December 07, 2004 8:40 PM > > To: Warwick Burrows; Slide Users Mailing List > > Subject: Re: Cluster cache > > > > > > On Tue, 2004-12-07 at 18:10 -0800, Warwick Burrows wrote: > > > Hi James, > > > > > > I was hoping you could answer some questions about the > > cluster cache > > > design. We would like to go into production with Slide but doing so > > > requires the cluster cache implementation -- or no caching at all > > > which is not even an option :-) We need to know the cluster cache > > > mechanics so we can cater for them. > > > > > > - Are the updates (notifications) between servers performed > > > synchronously or asynchronously? > > > > They should be asynchronous. Daniel Florey wrote the > > notification mechanism, so he can confirm, but I'm pretty > > sure on this. When a resource is modified the server sends > > notifications to all subscribers that there are events > > waiting for them. The subscribers (other servers) then POLL > > the server and get a list of changed resources. Each > > subscriber then removes the resource in the list from their cache. > > > > > - If an update to a server fails will it be retried? > > > > It depends on where the failure is. If a subscriber is unable > > to POLL a server, it will retry. In fact, each subscriber > > periodically POLLs the server just to be sure it hasn't > > missed any notifications. The POLL frequency should be configurable. > > > > > > > > Any other design points I should be aware of? > > > > Not that I can think of. > > > > > > > > Incidentally I had mentioned that locks could be an issue with the > > > cache design in that two lock requests coming in at the > > same time may > > > both return with the lock. It isn't an issue for us though > > as locking > > > is controlled by our DAV applications and the lock information they > > > share is stored in a DB. Only one app is guaranteed to get the lock > > > and so create a Slide lock. One way to mitigate this > > problem for other > > > clients may be to allow for the "lockstore" store to be > > specifically > > > configured so that only lock related metadata isn't cached. > > > > ExtendedStore has five (I think) separate caches. You can set > > the size of each cache by setting parameters on the store. > > One of the caches is for locks. Take a look at the source for > > ExtendedStore, since I'm not sure where, if anywhere, the > > parameters are documented. > > > > -James > > > > > > > > Thanks, > > > Warwick > > > > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
