Class TxnDataset2Graph

All Implemented Interfaces:

public class TxnDataset2Graph extends TransactionalLock
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" - there is no overall "commit" or "abort". If failure/restart occurs, some graphs may have committed 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.)

See Also:
  • Constructor Details

    • TxnDataset2Graph

      public TxnDataset2Graph(org.apache.jena.graph.Graph primaryGraph, org.apache.jena.graph.Graph... otherGraphs)
  • Method Details

    • addGraph

      public void addGraph(org.apache.jena.graph.Graph graph)
    • removeGraph

      public void removeGraph(org.apache.jena.graph.Graph graph)
    • setPrimaryGraph

      public void setPrimaryGraph(org.apache.jena.graph.Graph graph)
    • begin

      public void begin(TxnType type)
      Description copied from interface: Transactional
      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.

      This operation is optional and some implementations may throw a JenaTransactionException exception for some or all TxnType values.

      See Transactional.begin(ReadWrite) for a form that is required of implementations.

      Specified by:
      begin in interface Transactional
      begin in class TransactionalLock
    • commit

      public void commit()
      Description copied from interface: Transactional
      Commit a transaction - finish the transaction and make any changes permanent (if a "write" transaction)
      Specified by:
      commit in interface Transactional
      commit in class TransactionalLock
    • abort

      public void abort()
      Description copied from interface: Transactional
      Abort a transaction - finish the transaction and undo any changes (if a "write" transaction)
      Specified by:
      abort in interface Transactional
      abort in class TransactionalLock
    • end

      public void end()
      Description copied from interface: Transactional
      Finish the transaction - if a write transaction and commit() has not been called, then abort
      Specified by:
      end in interface Transactional
      end in class TransactionalLock