commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Marek Zawirski (JIRA)" <j...@apache.org>
Subject [jira] Commented: (VFS-253) AbstractFileObject: wrong synchronization of content-related code
Date Mon, 11 May 2009 08:39:45 GMT

    [ 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.


Mime
View raw message