[VFS] cache on children

[Philippe Poulard <Ph...@sophia.inria.fr>]

hi,

I'm still using VFS RC7

I have an empty directory : AbstractFileObject#children = []
Then, some files are written inside, but children is still set to []
Thus, AbstractFileObject#getChildren() still gives []

I'd like to flush this damned cache, but everything is private :(

How to force my directory to refresh its children list ?

-- 
Cordialement,

               ///
              (. .)
  --------ooO--(_)--Ooo--------
|      Philippe Poulard       |
  -----------------------------
  http://reflex.gforge.inria.fr/
        Have the RefleX !

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

Re: [VFS] cache on children

[Robert Enyedi <re...@gmail.com>]

Hi Mario,

I like your proposal. It's simple and effective. But having option b) the
default wouldn't break backward compatibility?

One thing though I don't understand. At option b), why call resync() _after_
the resolveFile() call. Should it be before?

Regards,
Robert

On 3/30/06, Mario Ivankovits <ma...@ops.co.at> wrote:
>
> Hi Robert!
> > Mario, I know that the caching mechanism has high priority for VFS 1.1,
> but
> > what if until than we would have a utility class
> Fact is, that I should take the time to fix this annoying thing.
>
> So lets discuss what I have in mind. Basically your utility class is
> something I had in mind, just a little bit more integrated into VFS.
>
> I would try to implement this in VFS using the decorator pattern. In the
> end I wanted to have 3 caching strategies:
>
> a) manual - as it is now, but maybe provide a method called "resync()"
> b) perResolveFile - resync() once directly after a resolveFile
> c) perCall - resync() once before any method call on a fileObject method
> - this is your utility class but as a decorator for the FileObject so
> the user didnt see this - the downside here is that any "fo instanceof
> ...." no longer work, but no one should be required to do this, and I'll
> provide a helper class e.g. FileObjectUtils.instanceOf(fo, class)
>
> IMHO, version b should be the default. The caching strategy should be
> configurable per FileSytemManager instance.
>
> WDYT?
>
> Ciao,
> Mario
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-user-help@jakarta.apache.org
>
>

Re: [VFS] cache on children

[Mario Ivankovits <ma...@ops.co.at>]

Hi Robert!
> Mario, I know that the caching mechanism has high priority for VFS 1.1, but
> what if until than we would have a utility class
Fact is, that I should take the time to fix this annoying thing.

So lets discuss what I have in mind. Basically your utility class is
something I had in mind, just a little bit more integrated into VFS.

I would try to implement this in VFS using the decorator pattern. In the
end I wanted to have 3 caching strategies:

a) manual - as it is now, but maybe provide a method called "resync()"
b) perResolveFile - resync() once directly after a resolveFile
c) perCall - resync() once before any method call on a fileObject method
- this is your utility class but as a decorator for the FileObject so
the user didnt see this - the downside here is that any "fo instanceof
...." no longer work, but no one should be required to do this, and I'll
provide a helper class e.g. FileObjectUtils.instanceOf(fo, class)

IMHO, version b should be the default. The caching strategy should be
configurable per FileSytemManager instance.

WDYT?

Ciao,
Mario


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

Re: [VFS] cache on children

[Robert Enyedi <re...@gmail.com>]

Hi,

Yep, this was an issue for me too :-)

Mario, I know that the caching mechanism has high priority for VFS 1.1, but
what if until than we would have a utility class (say
NonCachedFileOperations) for file operations that require non-cached file
information? For instance in JCommander we resorted to writing wrappers for
methods like getChildren(), delete() and mkdir() in which we call the
close() method for the involved files or the parents of the involved files.

Later on, in order not to break backward compatibility, as the caching issue
is architecturally fixed, these wrapper methods would have the close() calls
removed. The utility class might be a better solution than to inline the
close() calls to the client code.

Regards,
Robert

On 3/30/06, Mario Ivankovits <ma...@ops.co.at> wrote:
>
> Hi!
> > I have an empty directory : AbstractFileObject#children = []
> > Then, some files are written inside, but children is still set to []
> > Thus, AbstractFileObject#getChildren() still gives []
> >
> > I'd like to flush this damned cache, but everything is private :(
> :-) Its by far the most asked question.
>
> call directory.close() - this will refresh the cache too.
>
> Ciao,
> Mario
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-user-help@jakarta.apache.org
>
>

Re: [VFS] cache on children

[Mario Ivankovits <ma...@ops.co.at>]

Hi!
> I have an empty directory : AbstractFileObject#children = []
> Then, some files are written inside, but children is still set to []
> Thus, AbstractFileObject#getChildren() still gives []
>
> I'd like to flush this damned cache, but everything is private :(
:-) Its by far the most asked question.

call directory.close() - this will refresh the cache too.

Ciao,
Mario


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