commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Johan Lindquist" <>
Subject Re: [VFS] FileSystem close
Date Sun, 04 Jul 2004 12:51:24 GMT
On Sun, 04 Jul 2004 08:13:24 +0200, Mario Ivankovits <>  

> 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?



> --
> Mario
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

you too?

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message