public interface IVCache<V extends BigdataValue,T>
BigdataValue cached on an IV.
This interface is designed to support the query plan generator. The
BigdataValue is cached when a query plan decides that the
materialized value is required for a downstream operator.
Both IV and BigdataValue can cache one another. The pattern
for caching is that you always cache the IV on the
BigdataValue using BigdataValue.setIV(IV). However, the
BigdataValue is normally NOT cached on the IV. The exception
is when the BigdataValue has been materialized from the IV by
joining against the lexicon.
| Modifier and Type | Method and Description |
|---|---|
V |
asValue(LexiconRelation lex)
If the value is not already cached, then inflate an inline RDF value to a
BigdataValue and cache it on a private field. |
IV<V,T> |
clone(boolean clearCache)
Return a copy of this
IV. |
V |
getValue()
Return a pre-materialized RDF
BigdataValue which has been cached
on this IV by a previous invocation of
asValue(LexiconRelation). |
boolean |
hasValue()
Returns true if the RDF
BigdataValue has been pre-materialized
and cached on this IV. |
V |
setValue(V val)
Set the
BigdataValue on the cache. |
V asValue(LexiconRelation lex) throws UnsupportedOperationException
BigdataValue and cache it on a private field.
Note: Query plans are responsible for ensuring that IVs have been
materialized before operators are evaluated which invoke this method.
This pattern ensures that efficient batch operators are used to
materialize Values, and thereby avoids heavy RMI overhead in
scale-out, and provides operators which use getValue() with a
simple method signature which does not require access to the lexicon.
Query plans are also responsible for dropping variables once they are no
longer needed or, in the case of large values and BLOBs, dropping the
cached BigdataValue when possible in order to avoid excess
network and heap overhead.
lex - The lexicon relation (this is required in order to access the
BigdataValueFactory for the namespace associated with
lexicon when we materialize an inline IV).BigdataValue.UnsupportedOperationException - if the IV does not represent something which can be
materialized. For example, a dummy value or a "null".V setValue(V val)
BigdataValue on the cache.
Note: This is normally invoked by asValue(LexiconRelation)
during a lexicon join cache a newly materialized Value on the
IV.
val - The BigdataValue.V getValue() throws NotMaterializedException
BigdataValue which has been cached
on this IV by a previous invocation of
asValue(LexiconRelation).BigdataValue.NotMaterializedException - if the value is not cached.IV<V,T> clone(boolean clearCache)
IV.
Note: This method exists to defeat the hard reference from the IV
to the cached BigdataValue in order to avoid a memory leak when
the IV is used as the key in a weak value cache whose value is
the BigdataValue. Therefore, certain IV implementations
MAY return this when they are used for limited collections. The
vocabulary IVs are the primary example. For the same reason, we do not
need to recursively break the link from the IV to the
BigdataValue for IVs which embed other IVs.
clearCache - When true the cached reference (if any) will NOT
be set on the copy.(Thread-local
cache combined with unbounded thread pools causes effective memory
leak)boolean hasValue()
BigdataValue has been pre-materialized
and cached on this IV.Copyright © 2006–2019 SYSTAP, LLC DBA Blazegraph. All rights reserved.