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
================================================================

Reply via email to