Mailing-List: contact dev-help@commons.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Commons Developers List" <dev@commons.apache.org>
Received-SPF: pass (nike.apache.org: domain of jak-commons-dev@m.gmane.org
 designates 80.91.229.2 as permitted sender)
To: dev@commons.apache.org
From: =?UTF-8?B?SsO2cmc=?= Schaible <joerg.schaible@gmx.de>
Subject: Re: [vfs] VFS.getManager and FileCache
Date: Thu, 13 Aug 2009 09:52:48 +0200
Lines: 35
Message-ID: <h60goj$2ad$1@ger.gmane.org>
References: <h5e6d2$dpm$1@ger.gmane.org>
 <FAD140A6C8872442B36609E361093979D9E8F980@ex1>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8Bit
User-Agent: KNode/0.10.9
Sender: news <news@ger.gmane.org>

Hi Mario,

coming back to this now again ... ;-)

Mario Ivankovits wrote at Donnerstag, 6. August 2009 17:36:

> Hi!
> 
> Using weak ref as default seems not too bad. However, since the file
> objects have just their parent cached it might lead to much more file
> system access then now as a parent might need to refresh its children.
> 
> I tried to kick a discussion about caching at all already [1].

Ah, yes, interesting.

> I still think going the mount/unmount way and leaving all the
> concurrency/threading issues up to the application makes more sense.

+1, we might provide a synchronizing wrapper like it is done with
Collections.synchronizedXXX() methods. Actually I'd deprecate the
FM.resolveFile here in favor to mount/unmount simply to make it explicit
that you're doing something fundamental different than with FO.resolveFile.

> Means, VFS is no longer thread safe by default and you have to deal with
> thread safety only if you use the object returned from mount() in
> differente threads. Also, by unmounting (equals filesystem.close()) we can
> easily get rid of any used underlaying resources.

Currently I am diving deeper into the code, since even with the
WeakRefFilesCache our connections to the SFTP server are not closed even
when we keep no reference to any FileObject anymore and they are GCed ...
go hunting ;-)

- Jörg


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