I think the first solution to see how JCS behaves is to stick to the properties file. If JCS can be configured differently than you could make the component Parameterizable.
Carsten > -----Original Message----- > From: Corin Moss [mailto:[EMAIL PROTECTED] > Sent: Tuesday, March 02, 2004 9:34 AM > To: [EMAIL PROTECTED] > Subject: RE: JCS Based Cache - how to configure? > > > Hi Guys, > > The more I look at JCS, the more interesting it gets. The > simplest way to use it is to simply instantiate a JCS object, > and configure it using a "cache configuration file" - > obviously then the JCS object would be wrapped appropriately. > > If we were to use JCS at its most generic level then the user > could easily use any member store they wanted simply by > configuring properly. The only problem I really have is the > nature of the configuration. It is essentially a properties > file. Obviously this should be done within the cocoon xconf > - not an external file. How have you handled this in the > past? Are there any examples I can look at which do > something similar? > > Sorry about the volume of mail - this problem has really > caught my interest :) > > Thanks, > > Corin > > -----Original Message----- > From: Corin Moss > > Sent: Tuesday, 2 March 2004 8:59 p.m. > To: [EMAIL PROTECTED] > Subject: RE: JCS Based Cache > > > > You have a good point there - I'm simply going to have to > replace the DefaultPersistentStore at my end (for testing > only of course ;) > > One thing that has occurred to me whilst hammering the JISP > based store, and looking at the code in a bit more depth, is > that all of the perceived problems come as a result of the > incredibly high iowait generated whilst accessing the store > (mostly while writing I think.) I notice that the > AbstractReadWriteStore within the Excalibur components uses > FIFOReadWriteLock as the lock - has anyone got much > experience with this? If there's a bug in there, it's > possible that it's not relinquishing locks properly - which > would most likely manifest in very high iowait (I theorise ;) > I know that there are known issues with our version of JISP, > but I'd like to be reassured first-hand that the read/write > lock implementation we're currently using is totally robust. > > JCS does have its own R/W lock of course - but I'd love not > to have to change too many classes ;) > > Cool, > > Corin > > -----Original Message----- > From: Bertrand Delacretaz [mailto:[EMAIL PROTECTED] > > Sent: Tuesday, 2 March 2004 8:45 p.m. > To: [EMAIL PROTECTED] > Subject: Re: JCS Based Cache > > > Le Mardi, 2 mars 2004, à 08:16 Europe/Zurich, Corin Moss a écrit : > > > ... I guess conceptually this really belongs within the > > > Avalon-Excalibur-store framework, as it will sit along side > > > AbstractJispFilesystemStore rather than on top of it... > > Makes sense but I don't think it prevents you from > implementing a Store > > in the Cocoon source tree for now, like the (broken AFAIK) > > org.apache.cocoon.components.store.impl.FilesystemStore which simply > > extends AbstractFilesystemStore. > > It can always be moved to Avalon later on if needed, but it might be > > easier to work on it "here" for now. > > What I don't see is how you can configure a different Store than the > > DefaultPersistentStore, have you figured this out already? Cocoon uses > > DefaultPersistentStore by default but I didn't find where this is > > defined. > > -Bertrand > > ================================================================ > CAUTION: This e-mail and any attachment(s) contains > information that is intended to be read only by the named > recipient(s). It may contain information that is > confidential, proprietary or the subject of legal privilege. > This information is not to be used by any other person and/or > organisation. If you are not the intended recipient, please > advise us immediately and delete this e-mail from your > system. Do not use any information contained in it. > > ================================================================ > For more information on the Television New Zealand Group, > visit us online at http://www.tvnz.co.nz > ================================================================ > > ================================================================ > CAUTION: This e-mail and any attachment(s) contains > information that is intended to be read only by the named > recipient(s). It may contain information that is > confidential, proprietary or the subject of legal privilege. > This information is not to be used by any other person and/or > organisation. If you are not the intended recipient, please > advise us immediately and delete this e-mail from your > system. Do not use any information contained in it. > > ================================================================ > For more information on the Television New Zealand Group, > visit us online at http://www.tvnz.co.nz > ================================================================ >
