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 IV
s have been
materialized before operators are evaluated which invoke this method.
This pattern ensures that efficient batch operators are used to
materialize Value
s, 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 IV
s which embed other IV
s.
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.