com.bigdata.rdf.sparql.ast.cache

Class DescribeCache

java.lang.Object

com.bigdata.rdf.sparql.ast.cache.DescribeCache

All Implemented Interfaces:

IDescribeCache

public class DescribeCache
extends Object
implements IDescribeCache

An interface providing a maintained DESCRIBE cache for some AbstractTripleStore.

Author:

Bryan Thompson FIXME MVCC VIEWS: The same integration issue also needs to be addressed for the CacheConnectionImpl for named solution sets. TODO Support hash partitioned and remove DESCRIBE cache instances. These will need access to a service that resolves BigdataURI s to IVs efficiently. That service can be exposed using the NSS or using jini/River.

Constructor Summary

Constructors

Constructor and Description
DescribeCache(HTree map)

Method Summary

Methods

Modifier and Type	Method and Description
void	close()
void	destroy() Destroy the cache.
void	insert(IV<?,?> iv, org.openrdf.model.Graph g) Insert/update the cache entry for an IV.
void	invalidate(Set<IV<?,?>> ivs) Invalidate the identified cache entries.
org.openrdf.model.Graph	lookup(IV<?,?> iv) Lookup and return the cache entry.

Methods inherited from class java.lang.Object

clone, equals, finalize, getClass, hashCode, notify, notifyAll, toString, wait, wait, wait

Constructor Detail

DescribeCache

public DescribeCache(HTree map)

Method Detail

close

public void close()

destroy

public void destroy()

Description copied from interface: IDescribeCache

Destroy the cache.

Specified by:

destroy in interface IDescribeCache

insert

public void insert(IV<?,?> iv,
          org.openrdf.model.Graph g)

Insert/update the cache entry for an IV. TODO Compute the sketch and use an efficient representation for the describe graph. The insert should be vectored, scalable, and page oriented (blob stream API). The only scalable way to compute and store the sketch is to stream onto a buffer backed by temporary file, computing the sketch as we go and then replay the stream into a compact representation for the resource description. However, note that the API currently presumes that the Graph is transmitted as a unit. A GraphQueryResult provides an iterator oriented view of a graph more suitable to the transmission of large graphs and streaming graphs over a network.

The sketch can be used to compress the resource description. For example, it includes a frequency count of the predicates that can be used to assign Huffman codes. It would also be useful to be able to efficiently skip forward in the stream to the offset where specific edges are stored. Perhaps we could organize the edges using SPO (attributes and forward links) and POS (reverse links) projections. TODO If we explicit manage the raw records then we need to change how the metadata is declared. We would have a fixed length value (the addr on the backing store - either 4 or 8 bytes). We would also have to manage the storage explicitly, including explicitly deleting the backing raw record for each cache entry when that cache entry is invalidated.

Specified by:

insert in interface IDescribeCache

Parameters:

iv - The IV.

g - The Graph that describes that IV. TODO Vector inserts. TODO We probably need to include the timestamp of the database view from which the resource description was constructed.

lookup

public org.openrdf.model.Graph lookup(IV<?,?> iv)

Description copied from interface: IDescribeCache

Lookup and return the cache entry.

Specified by:

lookup in interface IDescribeCache

Parameters:

iv - The IV.

Returns:

The cache entry -or- null if there is no entry for that IV. TODO Vector lookups for query. We will need to use that to support a star-join against the DESCRIBE cache (leveraging materialized joins). TODO Offer a stream oriented response. For a single Graph , that could be a GraphQueryResult. For vectored lookups, this might be a stream of binding sets (vectored lookups make sense primarily in star joins, so this would really be the signature for the star-join operator).

invalidate

public void invalidate(Set<IV<?,?>> ivs)

Invalidate the identified cache entries. TODO Invalidation should probably for lastCommitTime+1 (that is, anything after the most current lastCommitTime). However, there is still a race condition when something is invalidated while there is a concurrent request to describe that thing. This can probably be solved by passing along the timestamp that the DESCRIBE query is reading on to the DescribeCacheUpdater and from there to the DESCRIBE cache. We always should prefer the description of a resource associated with the most current view of the database.

Specified by:

invalidate in interface IDescribeCache

Parameters:

ivs - The IVs for the cache entries to be invalidated.