db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Oystein.Grov...@Sun.COM (Øystein Grøvlen)
Subject Re: new uses for basic services cache - looking for advice
Date Thu, 05 Jan 2006 12:27:24 GMT
>>>>> "MM" == Mike Matrigali <mikem_app@sbcglobal.net> writes:

    MM> it is ugly, but a way to store duplicate keys in a hash table is
    MM> to store lists as the object in the hash table rather than the
    MM> object itself.  For instance in the store/lang interface where
    MM> store returns a hash table with a requested result set, if duplicates
    MM> are allowed it stores the object if there is 1 or a list if there
    MM> is more than one.  The ugly part is that it requires a class comparison
    MM> to tell what kind of thing is being returned.

Storing a list of items per hash entry will also beat the purpose of
using the cache to limit the number of items to the size of the
cache's hash table.

    MM> Having  said  that I  agree  that a  new  implementation  may be  more
    MM> appropriate, as the desire is to get the cache manager to track the
    MM> LRU nature of the individual items in the duplicate list.  And it
    MM> would be nice if it walked the list and asked the "is busy" question
    MM> to each object - this may require a new interface to be implemented
    MM> by each object to make it more generic.

I agree.

    MM> As I have said before this cache code is relatively small, and creating
    MM> a new implementation for open files seems like a good approach.
    MM> At the same time I think it might make sense to have a server wide
    MM> service providing this open file cache, rather than hidden in the
    MM> raw store implementation.  I think there is currently a problem with
    MM> sort because it does not also go through a open file cache - and there
    MM> are some security manager issues which also may be because there is
    MM> not one path to do I/O to files.

I agree that some general file cache that could be used by several
mechanism it to be preferred.  I also think this is the best way to
guarantee a limit on the total number of open file descriptors.

What is not clear to me, is whether the objects to be cached can be
RAFContainer objects.  It seems to be that some of the code assumes
that there is only a single RAFContainer object per container (e.g,
truncation and backup).  The serialization of accesses to a file that
we are trying to avoid for read operations, may be assumed by other


View raw message