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:
    DatasetGraphMapLink, DatasetGraphOne
    • Constructor Detail

      • TxnDataset2Graph

        public TxnDataset2Graph​(Graph primaryGraph,
                                Graph... otherGraphs)
    • Method Detail

      • addGraph

        public void addGraph​(Graph graph)
      • removeGraph

        public void removeGraph​(Graph graph)
      • setPrimaryGraph

        public void setPrimaryGraph​(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