binding/mdsal-binding-api/src/main/java/org/opendaylight/mdsal/binding/api/TransactionChain.java

   1 /*
   2  * Copyright (c) 2014 Cisco Systems, Inc. and others.  All rights reserved.
   3  *
   4  * This program and the accompanying materials are made available under the
   5  * terms of the Eclipse Public License v1.0 which accompanies this distribution,
   6  * and is available at http://www.eclipse.org/legal/epl-v10.html
   7  */
   8 package org.opendaylight.mdsal.binding.api;
   9
  10 import org.opendaylight.yangtools.concepts.Registration;
  11
  12 /**
  13  * A chain of transactions. Transactions in a chain need to be committed in sequence and each transaction should see
  14  * the effects of previous committed transactions as they occurred. A chain makes no guarantees of atomicity across
  15  * the chained transactions - the transactions are committed as soon as possible in the order that they were committed.
  16  * This behaviour is different from the default AsyncDataBroker, where a transaction is always created from the current
  17  * global state, not taking into account any transactions previously committed by the calling thread. Due to
  18  * the asynchronous nature of transaction submission this can lead to surprising results. If a thread executes
  19  * the following sequence sufficiently quickly:
  20  *
  21  * <code>
  22  * AsyncWriteTransaction t1 = broker.newWriteOnlyTransaction();
  23  * t1.put(id, data);
  24  * t1.commit();
  25  *
  26  * AsyncReadTransaction t2 = broker.newReadOnlyTransaction();
  27  * Optional&lt;?&gt; maybeData = t2.read(id).get();
  28  * </code>
  29  * it may happen, that it sees maybeData.isPresent() == false, simply because t1 has not completed the processes
  30  * of being applied and t2 is actually allocated from the previous state. This is obviously bad for users who create
  31  * incremental state in the datastore and actually read what they write in subsequent transactions. Using
  32  * a TransactionChain instead of a broker solves this particular problem, and leads to expected behavior: t2 will always
  33  * see the data written in t1 present.
  34  */
  35 public interface TransactionChain extends Registration, TransactionFactory {
  36     /**
  37      * Create a new read only transaction which will continue the chain.
  38      *
  39      * <p>
  40      * The previous write transaction has to be either SUBMITTED ({@link WriteTransaction#commit commit} was invoked)
  41      * or CANCELLED ({@link #close close} was invoked).
  42      *
  43      * <p>
  44      * The returned read-only transaction presents an isolated view of the data if the previous write transaction was
  45      * successful - in other words, this read-only transaction will see the state changes made by the previous write
  46      * transaction in the chain. However, state which was introduced by other transactions outside this transaction
  47      * chain after creation of the previous transaction is not visible.
  48      *
  49      * @return New transaction in the chain.
  50      * @throws IllegalStateException if the previous transaction was not SUBMITTED or CANCELLED.
  51      * @throws TransactionChainClosedException if the chain has been closed.
  52      */
  53     @Override
  54     ReadTransaction newReadOnlyTransaction();
  55
  56     /**
  57      * Create a new write-only transaction which will continue the chain.
  58      *
  59      * <p>
  60      * The previous write transaction has to be either SUBMITTED ({@link WriteTransaction#commit commit} was invoked)
  61      * or CANCELLED ({@link #close close} was invoked)
  62      *
  63      * <p>
  64      * The returned write-only transaction presents an isolated view of the data if the previous write transaction was
  65      * successful - in other words, this write-only transaction will see the state changes made by the previous write
  66      * transaction in the chain. However, state which was introduced by other transactions outside this transaction
  67      * chain after creation of the previous transaction is not visible
  68      *
  69      * <p>
  70      * Committing this write-only transaction using {@link WriteTransaction#commit commit} will commit the state
  71      * changes in this transaction to be visible to any subsequent transaction in this chain and also to any transaction
  72      * outside this chain.
  73      *
  74      * @return New transaction in the chain.
  75      * @throws IllegalStateException if the previous transaction was not SUBMITTED or CANCELLED.
  76      * @throws TransactionChainClosedException if the chain has been closed.
  77      */
  78     @Override
  79     WriteTransaction newWriteOnlyTransaction();
  80
  81     /**
  82      * Create a new read-write transaction which will continue the chain.
  83      *
  84      * <p>
  85      * The previous write transaction has to be either SUBMITTED ({@link WriteTransaction#commit commit} was invoked)
  86      * or CANCELLED ({@link #close close} was invoked).
  87      *
  88      * <p>
  89      * The returned read-write transaction presents an isolated view of the data if the previous write transaction was
  90      * successful - in other words, this read-write transaction will see the state changes made by the previous write
  91      * transaction in the chain. However, state which was introduced by other transactions outside this transaction
  92      * chain after creation of the previous transaction is not visible.
  93      *
  94      * <p>
  95      * Committing this read-write transaction using {@link WriteTransaction#commit commit} will commit the state changes
  96      * in this transaction to be visible to any subsequent transaction in this chain and also to any transaction outside
  97      * this chain.
  98      *
  99      * @return New transaction in the chain.
 100      * @throws IllegalStateException if the previous transaction was not SUBMITTED or CANCELLED.
 101      * @throws TransactionChainClosedException if the chain has been closed.
 102      */
 103     @Override
 104     ReadWriteTransaction newReadWriteTransaction();
 105 }