[kepler-dev] Replacing DataCacheManager with CacheManager.

Kevin Ruland kruland at ku.edu
Thu Dec 8 07:52:22 PST 2005


Hi.

One of the tickets assigned to me is to implement the cache expiration
stuff so, in particular, the ecogrid queries are better behaved.  I was
expecting to try to migrate the old ecogrid mechanism from the
DataCacheManager to the new CacheManager before getting this to work. 
However, I have some questions. 

The resultsets returned from the ecogrid queries do not have anything
resembling an lsid which is the primary key into the CacheManager.  We
could hack together an lsid based on something like the search criteria,
but strictly speaking this is not an lsid.  In addition, there is no
real guarantee that the resultset returned for the same query will
always be the same result set.  For example, additional Digir providers
are available, or new data has been added to metacat, etc.

I'm thinking we need some kind of internal lsid generator which can
return new lsids for the local application.  Either we'd have to have
the objects with these internal (localhost?) lsids always have "session"
lifespan, or we'll have to come up with a mechanism which always returns
the same lsid for any arbitrary input.  Maybe something like:

class LSIDGenerator {

  static LSID generate( Object o );

}

Some kind of magic checksum is computed on o and used in the lsid.  So
when somebody does an Ecogrid quick search, the contents of the text box
combined with the EcogridQueryEndpoint are passed into the generate
method.  Note:  both these things are strings.

A unique mapping from Object (or maybe the less general case String) ->
LSID could then be used to lookup the resultset (or other object) from
previously executed queries.

I think we have the same problem when trying to use the CacheManager as
a repository for intermediate results generated as part of a workflow.

Kevin



More information about the Kepler-dev mailing list