Yeah, they do - I don't see any point in changing them. My question was really more about whether we're sure the current locks are problem free. I see no reason to suspect otherwise, but I thought the question should be posed. The lock used is:
EDU.oswego.cs.dl.util.concurrent.FIFOReadWriteLock >From what I can tell it looks to be a very solid implementation. I'll proceed without worrying about it at this point I think :) Corin -----Original Message----- From: Bertrand Delacretaz [mailto:[EMAIL PROTECTED] Sent: Tuesday, 2 March 2004 9:21 p.m. To: [EMAIL PROTECTED] Subject: Re: JCS Based Cache Le Mardi, 2 mars 2004, à 08:59 Europe/Zurich, Corin Moss a écrit : > ...JCS does have its own R/W lock of course - but I'd love not to have > to change too many classes ;) I have no idea how the current locks work, but in this case the on-disk Store is going to be private to a single Cocoon instance, right? If so, simple object-based in-memory locks would do - but maybe JCS or the current Store already work this way? -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 ================================================================
