commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Johan Lindquist" <jo...@kawoo.co.uk>
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 <imario@apache.org>  
wrote:

> 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: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>



-- 
you too?

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