I don't think any of them would allow for something quite that simple, but I believe that they typically work over TCP.
-- Allen On Thu, 2006-01-12 at 07:59, John Hoffmann wrote: > Do these open source caching schemes not provide cache invalidation via > a URL call? > > Previous teams I led developed a REST style (before REST had a name) > cache manager that could be called with a key. When called, it would > also read the list of hosts from a properties file and exercise the same > cache invalidation message on all other hosts in the cluster. > > blogs.sun.com/invalidate_cache.jsp?key=foo_bar:123 > > when hit, that would clear the cache for localhost (say blogs2.sun.com), > and then call: > > blogs1.sun.com/invalidate_cache.jsp?key=foo_bar:123 > blogs3.sun.com/invalidate_cache.jsp?key=foo_bar:123 > > -John > > Allen Gilliland wrote: > > >I think the short answer to his question is, no, we don't support clustered > >environments. It's definitely something we are working towards though. > > > >Why can't we run clustered? The main reason I know if is that our > >presentation caches don't support clustering, so unless you are willing to > >set the timeout value to something fairly low and let them get out of sync > >for a little while then that's one roadblock. Currently we don't do object > >caching, but that is going to change now, so that is another item that will > >need consideration. > > > >File uploads are not something that I think Roller should have to worry > >about actually. If someone wants to share their file uploads between > >machines then they can do that via the filesystem, i.e. use something like > >nfs. > > > >The other clustering issue is the scheduled tasks. There is no > >locking/synchronization for multiple machines running scheduled tasks. It's > >pretty easy to bypass this one by running the tasks outside the webapp > >though. > > > >-- Allen > > > > > >On Wed, 2006-01-11 at 14:22, Matt Raible wrote: > > > > > >>Right, for a clustered environment (which Roller should support - even > >>if file uploads and such don't work so well) - we'd need to use JBoss > >>TreeCache or OSCache. I've used OSCache (with JGroups) with good > >>success - but we did have to modify some files for Hibernate 3. > >> > >>http://opensymphony.com/oscache/wiki/Hibernate.html > >> > >>Matt > >> > >>On 1/11/06, Jeff Blattman <[EMAIL PROTECTED]> wrote: > >> > >> > >>>stupid newbie comment ... does roller support multi instances? if it > >>>did, l2 cache becomes problematic unless it's a super-smart > >>>implementation that sync's itself across instances. > >>> > >>>Allen Gilliland wrote: > >>> > >>> > >>> > >>>>yes? no? anybody? > >>>> > >>>>i'd like to commit a *very* modest version of a hibernate L2 cache which > >>>>would use ehcache and only apply to a few objects ... RollerPropertyData, > >>>>WebsiteData, and UserData. > >>>> > >>>>-- Allen > >>>> > >>>> > >>>>On Mon, 2006-01-09 at 18:59, Allen Gilliland wrote: > >>>> > >>>> > >>>> > >>>> > >>>>>One of the things that we currently do not take advantage of is object > >>>>>level caching. Hibernate makes it pretty easy to add an L2 cache on a > >>>>>class by class basis, so I'd like to start by adding an L2 cache for a > >>>>>handful of classes like ... RollerPropertyData, WebsiteData, and > >>>>>UserData. All three of those classes are highly used and seldomly > >>>>>changed, so they are ideal for caching. > >>>>> > >>>>>We can play with a variety of possible cache implementations, but > >>>>>EhCache is the default and seems easiest to use at this point. > >>>>> > >>>>>Would anyone object to this? > >>>>> > >>>>>-- Allen > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>> > >>>> > >>>> > >>> > >>> > > > > > > >
