Hello,
I was trying to understand the concurrency semantics of VFS2, and I found
some comments which contradict each other and all of them also contradict
the implementation:
The current implementation allows multiple input streams and multiple
random access and a single outputstream PER THREAD. The close() will close
all of them (for the current thread).
DefaultFileContent.java
#401: getInputStream -> no limit on number of opens, all independent,
track by threadlocal, wraps FileObject.getInputStream with
FileContentInputStream
#430: getRandomAccessContent -> no limit on number of opens, all
independent(?), track by threadlocal, wraps
FileObject.getRandomAccessContent in FileRandomAccessContent
#468: getOutputStream -> allows only one open per thread, track by
threadlocal, wraps FileObject.getOutputStream in FileContentOutputStream
#495: close() -> closes all (up until first exception!) streams tracked in
thread local (only). Discards the not-closes streams in thread local in
all cases (why?)
#584: isOpen() -> returns true if any of the tracked streams in current
thread are still open
#596: isOpenGlobal() -> returns true if any of the threads have still
tracked streams open - not in Interface
While I can understand why the clone is limited to the single thread, I am
not particular clear on the restriction for a single output stream but
multiple random access. I can understand that multiple output streams do
cause problems, but only/even more so with multiple threads. So the
current limit for one OS/thread seems aribitrary.
Actually having a real atomic append only semantic (for multiple writers
in same of different thread) would be very helpfull for OS. (if I write x
bytes in a single write() operation they will always land in a atomic
chunk after the last write of somebody else). Some providers might not be
able to provide it at all or not across multiple JVMs -> possibility for
capabulities?
And here are the incomplete/contradicting specifications:
FileContent.java:
#38 * A file may have multiple InputStreams open at the same time.
#149 * <p>There may only be a single input or output stream open for the
* file at any time.
InputStream getInputStream() throws FileSystemException;
#167 * <p>There may only be a single input or output stream open for the
* file at any time.
OutputStream getOutputStream() throws FileSystemException;
#186 * <p>There may only be a single input or output stream open for the
* file at any time.
RandomAccessContent getRandomAccessContent(final RandomAccessMode
mode) throws FileSystemException;
#203 * <p>There may only be a single input or output stream open for the
* file at any time.
OutputStream getOutputStream(boolean bAppend) throws
FileSystemException;
#217
* Closes all resources used by the content, including any open stream.
* Commits pending changes to the file.
* <p/>
* <p>This method is a hint to the implementation that it can release
* resources. This object can continue to be used after calling this
* method.
*/
void close() throws FileSystemException;
I would suggest you change the specification to eighter describe the
default implementation or to make it clear
that it is implementation specific (and to what degree and depending on
which capabilities)
If the concurrency semantic depends on the FileContent Implementation,
then I would say:
* The decision if you can have multiple open OutputStream or
RandomAccessContent handles depends
* on the actual implementation for the FileContent interface. This also
influences isOpen() and close() methods.
* For the default behavor see DefaultFileContent. You can always request
multiple independend InputStreams in
* the same or different threads.
(isOpenGlobal() is not in the interface only in the DefaultFileContent).
If you agree something needs to be changed, I am happy to open a JIRA
ISsue.
Gruss
Bernd
--
http://bernd.eckenfels.net
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
