locking in zipfs demo

[Rajendra.Gutupalli@Sun.com]

Alan Bateman wrote:
> Joel Uckelman wrote:
>> I'm puzzled by the ReentrantReadWriteLock used in ZipFilePath in various
>> place. It seems to be locking calls to getResolvedPathForZip(), which
>> sets the pathToZip member if it's null. Is there a reason for using a
>> lock for this instead of making pathToZip volatile like the offsets
>> ArrayList is?
>>   
> It looks like it was intended to support asynchronous close of the zip 
> file system, in which case it should be using fs.begin() and fs.end() 
> rather than its own lock (Rajendra - can you confirm this?).
Hi Alan,

I am alive :-)          gone into snooze mode on jdk7 and working on 
different projects. Sorry for delay in responding the mail.

The main intention of using lock is for each operation that accesses the 
zip file acquires the read lock, tests if the file system is closed and 
if so throws ClosedFileSystemException
and at the end releases the lock. The close method acquires the write 
lock and will wait until all threads are finished access the zip file.

Thanks
Rajendra