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?
Closing every file could be painful - at least to remember - but I think it would guarantee (more) that resources are released as required. Streams already require this and developers need to be careful with resources in general, so it is just a matter of education ;)
Realise now how the filesystem close would not work in multi-threaded environments either - unless it was made conditionally (using the counter you describe above) but then the cleanup method is definately better ...
Will fiddle with the thread-local work-around for the moment but it seems the use-count option is the way to proceed. I can have a look at it (time allowing) if you want some more feedback?
Thanks,
Johan
-- Mario
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
-- you too?
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
