* For a detailed explanation of how transaction are isolated and how transaction-local
* changes are committed to global data tree, see
* {@link AsyncReadTransaction}, {@link AsyncWriteTransaction},
- * {@link AsyncReadWriteTransaction} and {@link AsyncWriteTransaction#commit()}.
+ * {@link AsyncReadWriteTransaction} and {@link AsyncWriteTransaction#submit()}.
*
* <p>
* It is strongly recommended to use the type of transaction, which
* implementations may optimize the transaction for reading if they know ahead
* of time that you only need to read data - such as not keeping additional meta-data,
* which may be required for write transactions.
- *<p>
+ *
+ * <p>
* <b>Implementation Note:</b> This interface is not intended to be implemented
* by users of MD-SAL, but only to be consumed by them.
*
* @param <D>
* Type of data (payload), which represents data payload
*/
+@Deprecated(forRemoval = true)
public interface AsyncDataTransactionFactory<P extends Path<P>, D> {
/**
- * Allocates a new read-only transaction which provides an immutable snapshot of
- * the data tree.
- *<p>
+ * Allocates a new read-only transaction which provides an immutable snapshot of the data tree.
+ *
+ * <p>
* The view of data tree is an immutable snapshot of current data tree state when
* transaction was allocated.
*
* Preconditions for mutation of data tree are captured from the snapshot of
* data tree state, when the transaction is allocated. If data was
* changed during transaction in an incompatible way then the commit of this transaction
- * will fail. See {@link AsyncWriteTransaction#commit()} for more
+ * will fail. See {@link AsyncWriteTransaction#submit()} for more
* details about conflicting and not-conflicting changes and
* failure scenarios.
*
* Preconditions for mutation of data tree are captured from the snapshot of
* data tree state, when the transaction is allocated. If data was
* changed during transaction in an incompatible way then the commit of this transaction
- * will fail. See {@link AsyncWriteTransaction#commit()} for more
+ * will fail. See {@link AsyncWriteTransaction#submit()} for more
* details about conflicting and not-conflicting changes and
* failure scenarios.
*
* Since this transaction does not provide a view of the data it SHOULD BE
* used only by callers which are exclusive writers (exporters of data)
* to the subtree they modify. This prevents optimistic
- * lock failures as described in {@link AsyncWriteTransaction#commit()}.
+ * lock failures as described in {@link AsyncWriteTransaction#submit()}.
+ *
* <p>
* Exclusivity of writers to particular subtree SHOULD BE enforced by
* external locking mechanism.