Return-Path: Delivered-To: apmail-jakarta-commons-dev-archive@apache.org Received: (qmail 46249 invoked from network); 12 Feb 2002 19:46:55 -0000 Received: from unknown (HELO nagoya.betaversion.org) (192.18.49.131) by daedalus.apache.org with SMTP; 12 Feb 2002 19:46:55 -0000 Received: (qmail 29587 invoked by uid 97); 12 Feb 2002 19:46:58 -0000 Delivered-To: qmlist-jakarta-archive-commons-dev@jakarta.apache.org Received: (qmail 29569 invoked by uid 97); 12 Feb 2002 19:46:57 -0000 Mailing-List: contact commons-dev-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Help: List-Post: List-Id: "Jakarta Commons Developers List" Reply-To: "Jakarta Commons Developers List" Delivered-To: mailing list commons-dev@jakarta.apache.org Received: (qmail 29538 invoked from network); 12 Feb 2002 19:46:56 -0000 Message-ID: From: Aaron Smuts To: Jakarta Commons Developers List , flanandowska@yahoo.com Subject: RE: "dependant" Cache Filter (was [PROPOSAL] commons-filters) Date: Tue, 12 Feb 2002 14:46:39 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1B3FD.FCF113C0" X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N ------_=_NextPart_001_01C1B3FD.FCF113C0 Content-Type: text/plain; charset="iso-8859-1" If all your database access goes through managers that put, get, and invalidate elements in the cache, and you use JCS for your distributed caching, then this would work. This is what JCS is designed for. The caches can be distributed and the cache control doesn't have to reside in the same spot. You can structure it however you want -- centralized remote server or direct lateral communication. . . . . Aaron > -----Original Message----- > From: bayard@generationjava.com [mailto:bayard@generationjava.com] > Sent: Tuesday, February 12, 2002 2:40 PM > To: Jakarta Commons Developers List; flanandowska@yahoo.com > Subject: Re: "dependant" Cache Filter (was [PROPOSAL] commons-filters) > > > > On Tue, 12 Feb 2002, Lavandowska wrote: > > > Interesting idea. Do you have suggestions on how such an organization > > would be configured? Sounds rather messy to be specifying these > > "relationships" in web.xml. > > Yeah, I've not investigated how you'd specify the dependencies. Maybe the > web.xml would specify a url to find that config xml at or something. Are > there any general patterns for adding new xml config's? > > Could a simple rules engine fit? > > > > > > This could then be tied with a servlet that did redirection in a > > > configurable way, so that a request could be sent off to another > > > site. It > > > > I don't follow this part, why send it off to another site? > > Well, this part of the idea was a follow-on one. It gets into manual > load-balancing a touch, but what if I setup a handful of cache machines, > and then had one real tomcat. I could use the real tomcat for internal > stuff or something, and have all the users hitting the cache machines. > > The cache-filter would start to get up into being a web-cache server. So > possibly a bit too far in the future, but the idea seems valid. I'm not > sure if things like squid and the like allow you to build dependency > trees. > > Would be interesting to make the dependency concept dynamic, so that > database code/triggers could inform the right webpage etc. I don't know if > that would be considered ugly. > > I'm wandering :) > > Bay > > > -- > To unsubscribe, e-mail: unsubscribe@jakarta.apache.org> > For additional commands, e-mail: help@jakarta.apache.org> ------_=_NextPart_001_01C1B3FD.FCF113C0--