[
https://issues.apache.org/jira/browse/VFS-253?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12707936#action_12707936
]
Marek Zawirski commented on VFS-253:
------------------------------------
For our use case, I would like to set up one FileSystemManager for potentially
multi-threaded application or even multiple application not aware about each
other. I would like them to be unaware of each other as much as possible and
act with VFS FIleObject, that I provide them, in a way like they are given
ordinary VFS FileObject like any other.
Such behavior is possible for mentioned java.io.File that is immutable as you
said. So if application receives File or path, it can safely open another
stream if necessary. IMHO disallowing that for mutable FileObject (which would
require using some synchronization inside FileObject) is some limitation. The
reason for it being thread-safe is that I hope they could be more easily shared
then.
In present way, considering that FileSystems cache opened FileObjects at
FileSystemManager cache, it is impossible to easily and safely access
concurrently the same file using the same FileSystemManager -> you can get the
same FileObject. I would have to use separate FileSystemManagers instead, which
I consider as limitation, as it requires several "mountings" of the same file
systems or reduces the transparency of VFS, at least in my use case.
> AbstractFileObject: wrong synchronization of content-related code
> -----------------------------------------------------------------
>
> Key: VFS-253
> URL: https://issues.apache.org/jira/browse/VFS-253
> Project: Commons VFS
> Issue Type: Bug
> Affects Versions: 2.0
> Reporter: Marek Zawirski
>
> Creating content through {{AbstractFileObject#getContent()}} and
> {{DefaultFileContent}} itself seem to be synchronized, but closing the
> content by {{AbstractFileObject#close()}} and checking whether it is open, by
> {{AbstractFileObject#isContentOpen()}} are NOT synchronized.
> Both these methods miss some lock-object. For {{close()}} it may result in
> severe race condition in case of {{FileObject}} shared across more than one
> thread.
> BTW, thead-safeness of important VFS classes/interfaces like {{FileObject}}
> is not documented in javadoc.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
