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
  BigdataValueand 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  BigdataValuewhich has been cached
 on thisIVby a previous invocation ofasValue(LexiconRelation). | 
| boolean | hasValue()Returns true if the RDF  BigdataValuehas been pre-materialized
 and cached on thisIV. | 
| V | setValue(V val)Set the  BigdataValueon 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.