Hi Doug, I'm sure it's obvious, but I just want to mention that the central authority web service would have to have both read and write methods so any server could tell it when an insert or update had been performed.
I am also thinking that a publisher: subscriber model might be more performant as you'd get notified whenever a cache was tainted (usually fairly seldom) rather than having to ask if the cache was valid every time you read from the cache (more frequent). Obviously with a model like this the benefits of caching would become more marginal for fast changing data, so I'd make it object specific so you didn't have to cache comments or messages in chat windows. Best Wishes, Peter On 10/9/06 5:09 PM, "Doug Hughes" <[EMAIL PROTECTED]> wrote: > Well, as it relates to this, I'm thinking of a few options: > > First, by default, Reactor will assume a one-sever setup where the server > manages its own cache. > > Second, there will be a mechanism to clear cached items. > > Third, via configuration settings you can specify a specific web service URL > (obviously to a specific machine/ip) that would be the central authority for > caching. When specified each server would check with that central authority > to see if it is allowed to use a cached version of the data. > > But yea, not sure if that's even a good idea. :) Common people, what do you > think? > > Doug > > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > Behalf Of Sean Corfield > Sent: Monday, October 09, 2006 4:05 PM > To: [email protected] > Subject: Re: [Reactor for CF] Big speed update in latest commit > > And don't forget clustered servers where the same application will > have its own cache on each server instance (we have this scenario - we > are careful about our data usage patterns and what we cache but we > also have a web service driven cache updater that can be > programmatically triggered to refresh individual cached objects on > other servers in the cluster). > > As Barney says, this stuff can do your head in... > > On 10/9/06, Peter Bell <[EMAIL PROTECTED]> wrote: >> I may be the only one, but I don't love setting cache times as opposed to >> using an IsDirty mechanism. If another application may edit your data, it >> may edit it in a second or in a week. Satisficing on x minnutes as an >> acceptable latency is OK, but not great. >> >> I'd love to see optional object based query caching with an isdirty >> intercepting inserts, updates and deletes and a big warning message in the >> docs that said "if other applications touch your database or you have >> non-reactor db modifications or you use triggers, or you've written your > own >> queries using the query object that modify data, then don't use caching - >> otherwise enjoy". > > > -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- > -- -- > Reactor for ColdFusion Mailing List > [email protected] > Archives at: http://www.mail-archive.com/reactor%40doughughes.net/ > -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- > -- -- > > > > -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- > -- > Reactor for ColdFusion Mailing List > [email protected] > Archives at: http://www.mail-archive.com/reactor%40doughughes.net/ > -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- > -- > -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- Reactor for ColdFusion Mailing List [email protected] Archives at: http://www.mail-archive.com/reactor%40doughughes.net/ -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
