commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mario Ivankovits <ima...@apache.org>
Subject Re: [VFS] FileSystem close
Date Sun, 04 Jul 2004 06:13:24 GMT
Johan Lindquist wrote:

> So, something like this:
>
> FileSystemOptions fso = new FileSystemOptions();
> SftpFileSystemConfigBuilder.getInstance().setUserInfo(fso, new  
> TrustEveryoneUserInfo());
>
> FileObject inFile = fsManager.resolveFile("sftp://someurl", fso);
>
> // do something with the file
>
> fs = inFile.getFileSystem();
> fs.close();
>
> What are the general thoughts about this?

First, there is another workaround for the close problem in 
multithreaded environments if you create your own Manager (like 
VFS.getManager() does) but attach it to a threadLocal.
I have done this in our wep-application and use a servlet filter to 
ensure the manager is closed after the request.
I know, also only a workaround, but a "thread-safe" one ;-)

However, i see the problem and i would like to solve it in a clear way.

One solution could be to force the developer to close EVERY resolved 
file, that way we could maintain a "use-count" on the file-system and if 
this drop to zero a) automatically or b) by calling cleanup() on the 
manager close this filesystem.

Exposing the filesystem close() is not a solution, if you use a global 
manager (= one instance for all threads) you cant be sure no other 
thread will use the same filesystem and thus if you call close, it will 
unexpectedly closed for the other thread too.

I tend to implement this use-count, but we have to close EVERY file, 
even if we only used it to get e.g. the file-type.

What do you think?

--
Mario


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message