Martin,

I am catching up on emails from a long week of conferences and a little
vacation time so please forgive me if this response sounds redundant or at
all dense. Is your cache class to be used as an actual map cache to store
and retrieve map tiles? It kind of sounds like that as we often test to see
if cached tiles have been changed by counting pixels and their values
before generating new ones. If nothing has changed, leave them alone,
right? Can this class be used like that or is that the intent?

Adam

On Thu, Oct 11, 2012 at 1:02 PM, Mattmann, Chris A (388J) <
[email protected]> wrote:

> Hi Martin,
>
> Thanks for mentioning it and these classes seem very useful for managing
> Mapped collections which
> themselves are useful in the spatial metadata context. I see why they are
> necessary to tackle upfront.
>
> Cheers,
> Chris
>
> On Oct 11, 2012, at 9:38 AM, Martin Desruisseaux wrote:
>
> > Hello Chris
> >
> > Le 12/10/12 01:16, Mattmann, Chris A (388J) a écrit :
> >> This makes total sense to me, and allows to take advantage of
> downstream flexibility where we simply
> >> want to standardize on interfaces like Lists and Collections.
> >
> > Thanks a lot :-). Maybe the Cache class is also worth to mention (while
> not yet used in SIS). This class implements the Map interface and uses
> internally the java.util.concurrent package (including the
> ConcurrentHashMap). It provides a mechanism for blocking a thread which
> asked the value for a key when that particular value is in process of being
> calculated by another thread. It also replaces automatically the references
> to oldest values by weak references when the "cost" of all entries is over
> a threshold. The "cost" is used-specified, but a good example is the amount
> of pixels in an image. The oldest values are replaced by weak references
> rather than discarded because if strong references still exist somewhere
> else in the application, removing the value from the Cache will not save
> anything. Quite the opposite, it would duplicate objects if the value is
> recomputed.
> >
> > The difference between Cache and WeakValueHashMap is that
> WeakValueHashMap has no concurrency support and uses only weak references
> (no mechanism replacing strong references by weak references after some
> cost threshold). WeakValueHashMap is used only for avoiding object
> duplications (reuse existing instances); it can't be used as a cache since
> it doesn't retain entries from being garbage collected.
> >
> >    Regards,
> >
> >        Martin
> >
>
>

Reply via email to