[jbosscache-dev] Pulling the FileCacheLoader from 3.0.0

Brian Stansberry brian.stansberry at redhat.com
Tue Apr 1 11:57:41 EDT 2008


Manik Surtani wrote:
> 
> On 1 Apr 2008, at 16:38, Brian Stansberry wrote:
>>>
>>> Re: FileChannel, locking is less important since I have implemented 
>>> locking on a per-Fqn basis in the FCL [1] - agreed the FileChannel 
>>> stuff may be better, but it's a less urgent need since locking isn't 
>>> a problem with the FCL anymore.
>>
>> If the FCL is used with a shared=true you need to coordinate access to 
>> the filesystem.
> 
> Unless I'm mistaken, the FileChannel lock won't do that either?
> 

Platform dependent.  From the javadoc of java.nio.channels.FileLock:

"Platform dependencies

This file-locking API is intended to map directly to the native locking 
facility of the underlying operating system. Thus the locks held on a 
file should be visible to all programs that have access to the file, 
regardless of the language in which those programs are written.

Whether or not a lock actually prevents another program from accessing 
the content of the locked region is system-dependent and therefore 
unspecified.

...

Some network filesystems permit file locking to be used with 
memory-mapped files only when the locked regions are page-aligned and a 
whole multiple of the underlying hardware's page size. Some network 
filesystems do not implement file locks on regions that extend past a 
certain position, often 230 or 231. In general, great care should be 
taken when locking files that reside on network filesystems."

> -- 
> Manik Surtani
> Lead, JBoss Cache
> manik at jboss.org
> 
> 
> 
> 
> 
> 

-- 
Brian Stansberry
Lead, AS Clustering
JBoss, a division of Red Hat
brian.stansberry at redhat.com



More information about the jbosscache-dev mailing list