[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