Pier Fumagalli wrote: > > So, at the end of the day, who is ALSO using the persistent > store? Only the cache? I'm getting lost in components, my > greps are not powerful enough (anymore) :-( > Only some others to cache prepared things, like the portal, batik or I think XSP as well. Perhaps it's only me but I think we (or I?) somehow confused the difference between a store and a cache. Imho a cache caches :) something for improved performance, but the system will still work the same way (only slower) if the cache gets lost (is cleared). But a store stores :) things, if they somehow got lost, the system is missing some information. So perhaps it's time to do this part for 2.2 right as well, skip the excalibur store and do it better?
Carsten > Pier > > On 20 Oct 2004, at 06:55, Carsten Ziegeler wrote: > > > The cache is an own component (called Cache) which has > currently one > > default implementation that uses a Store (component). Now I > think for > > such use cases a different Cache implementation is better. This > > implementation could directly "cache" the data without going via a > > store. > > > > Carsten > > > >> -----Original Message----- > >> From: Pier Fumagalli [mailto:[EMAIL PROTECTED] > >> Sent: Wednesday, October 20, 2004 2:26 AM > >> To: [EMAIL PROTECTED] > >> Subject: Re: FilesystemStore broken??? > >> > >> On 20 Oct 2004, at 01:01, Vadim Gritsenko wrote: > >>> Pier Fumagalli wrote: > >>>> > >>>> After a brief suggestion from Carsten, given that I > already have a > >>>> B-Tree indexing filesystem under my live application > (ReiserFS) I > >>>> wanted to switch the persistent store to be the > >> FilesystemStore, and > >>>> ignore all those JISP/JCACHE/EHCACHE/blablabla stuff... > >>>> Looking at my cocoon.xconf, I see this: > >>>> WARNING: FilesystemStore and JispStore are broken. > >>> > >>> FilesystemStore: > >>> > >>> It was consistently not working (IIRC) since 2.1 - which has > >>> significantly larger keys - and this means, store will create > >>> files with significantly larger file names - which do not fit > >>> into most file systems. > >>> > >>> [...] > >>> > >>> You can try and improve FilesystemStore. May be use some > >> hash for the > >>> file name? > >> > >> Yeah... Now that I know what I have to look at, I can give it a > >> shot... > >> I don't know the filename length on RaiserFS, but that's > what I want > >> to use :-P > >> > >> Frankly, having a B-Tree index on top of another B-Tree > index seems > >> kinda of a waste, that's why I don't want to use all those caching > >> things anymore... They're soooo Windows FAT-32!!! :-P > >> > >> Pier > >> > > > > >
