Sesame 2.x
integration.
Read-write operations use
#getConnection()to obtain a mutable view.
This delegates to either
#getUnisolatedConnection() or
#getReadWriteConnection() depending on how the Sail is configured.
Concurrent unisolated writers are supported if group commit is enabled, but
at most one unisolated writer will execute against a given Sail instance at a
time - other writers will be serialized. See
#getUnisolatedConnection() for more information on how to enable
group commit and how to write code that supports group commit.
Concurrent readers are possible, and can be very efficient. However, readers
MUST use a database commit point corresponding to a desired state of the
store, e.g., after loading some data set and (optionally) after computing the
closure of that data set. Use
#getReadOnlyConnection() to obtain a
read-only view of the database as of the last commit time, or
#getReadOnlyConnection(long) to obtain a read-only view of the
database as of some other historical point. These connections are safe to use
concurrently with the unisolated connection from
#getConnection().
Concurrent fully isolated read/write transactions against the same Sail are
also implemented in the bigdata SAIL. To turn on read/write transactions, use
the option
Options#ISOLATABLE_INDICES. If this option is set to true,
then
#getConnection() will return an isolated read/write view of the
database. Multiple concurrent read/write transactions are allowed, and the
database can resolve add/add conflicts between transactions. Unlike group
commit, these fully isolated read/write transactions will in fact execute
concurrently against the same Sail instance (rather than being serialized).
However, there is additional overhead for fully isolated read/write
transactions and graph update patterns can lead to unreconcilable conflicts
during updates (in which case one transaction will be a failed during the
validation phase). The highest throughput is generally obtained using
#getUnisolatedConnection() in which case you do not need to enabled
Options#ISOLATABLE_INDICES.
The
BigdataSail may be configured as as to provide a triple store
with statement-level provenance using statement identifiers. See
AbstractTripleStore.Options#STATEMENT_IDENTIFIERS and
Reification Done Right .
Quads may be enabled using
AbstractTripleStore.Options#QUADS.
However, note that
Options#TRUTH_MAINTENANCE is not supported for
AbstractTripleStore.Options#QUADS at this time. This may change in
the future once we decide how to handle eager materialization of entailments
with multiple named graphs. The basic problem is that:
merge(closure(graphA), closure(graphB))
IS NOT EQUALS TO
closure(merge(graphA, graphB))
There are two ways to handle this. One is to compute all inferences at query
time, in which case we are not doing eager materialization and therefore we
are not using Truth Maintenance. The other is to punt and use the merge of
their individual closures.