Class TxnDataset2Graph

A Transactional that passes the transaction operations down to transactions on
independent graphs.

There are limitations:

we can't atomically do all the commits together in the crash situation.

This Transactional maintains a MRSW policy because that is all that is
required of graphs in general.

It does cover the important case of one graph (DatasetGraphOne) where the one
graph is an InfGraph and should work when the graphs in the dataset is not changing or
when a new memory graph is added mid-transaction.

This is not "nested transactions" - theer is no overall "commit" or "abort". If
failure/restart occurs, some graphs may have commited and others not. It is the best
that can be done given for an arbitrary collection of graphs, backed by different
storage and having different capabilities.

Best practice is to change the graph membership outside of any transaction,
ideally at setup time of the object using this class. (Caution: SPARQL Update
can create graphs.)

Field Detail

TXN_DSG_GRAPH

Control whether to pass down transactions from the dataset to the graph in the
dataset. This should be set to "true"; setting it "false" causes the old,
non-transaction passing behaviour.

This is temporary flag during the transition because the change at Jena 3.7.0 needs
to be proven in real deployments as well as testing. "false" restores the Jena
3.6.0 and before behaviour (transactions not passed down). See JENA-1492.

removeGraph

setPrimaryGraph

begin

Start a transaction.
READ or WRITE transactions start in that state and do not change for the
lifetime of the transaction.

WRITE: this guarantees a WRITE will complete if commit() is
called. The same as begin(ReadWrite.WRITE).

READ: the transaction can not promote to WRITE,ensuring read-only
access to the data. The same as begin(ReadWrite.READ).

READ_PROMOTE: the transaction will go from "read" to "write" if an
update is attempted and if the dataset has not been changed by another write
transaction. See also Transactional.promote().

READ_COMMITTED_PROMOTE: Use this with care. The promotion will
succeed but changes from other transactions become visible.

Read committed: at the point transaction attempts promotion from "read" to
"write", the system checks if the dataset has change since the transaction started
(called begin). If READ_PROMOTE, the dataset must not have
changed; if READ_COMMITTED_PROMOTE any intermediate changes are
visible but the application can not assume any data it has read in the
transaction is the same as it was at the point the transaction started.