Search Results for

    Show / Hide Table of Contents

    Namespace Apache.Ignite.Core.Transactions

    Classes

    TransactionConfiguration

    Transactions configuration.

    TransactionDeadlockException

    Indicates a deadlock within Ignite transaction.

    This exception can be thrown from any cache method that modifies or reads data within a transaction with timeout (see TxStart(TransactionConcurrency, TransactionIsolation, TimeSpan, Int32) overload).

    TransactionHeuristicException

    Exception thrown whenever Ignite transaction enters an unknown state. This exception is usually thrown whenever commit partially succeeds. Cache will still resolve this situation automatically to ensure data integrity, by invalidating all values participating in this transaction on remote nodes.

    TransactionOptimisticException

    Exception thrown whenever Ignite transactions fail optimistically.

    TransactionRollbackException

    Exception thrown whenever Ignite transactions has been automatically rolled back.

    TransactionTimeoutException

    Exception thrown whenever Ignite transactions time out.

    Interfaces

    ITransaction

    Grid cache transaction.

    Cache transactions support the following isolation levels:

    • ReadCommitted isolation level means that always a committed value will be provided for read operations. With this isolation level values are always read from cache global memory or persistent store every time a value is accessed. In other words, if the same key is accessed more than once within the same transaction, it may have different value every time since global cache memory may be updated concurrently by other threads.
    • RepeatableRead isolation level means that if a value was read once within transaction, then all consecutive reads will provide the same in-transaction value. With this isolation level accessed values are stored within in-transaction memory, so consecutive access to the same key within the same transaction will always return the value that was previously read or updated within this transaction. If concurrency is Pessimistic, then a lock on the key will be acquired prior to accessing the value.
    • Serializable isolation level means that all transactions occur in a completely isolated fashion, as if all transactions in the system had executed serially, one after the other. Read access with this level happens the same way as with RepeatableRead level. However, in Optimistic mode, if some transactions cannot be serially isolated from each other, then one winner will be picked and the other transactions in conflict will result in TransactionOptimisticException being thrown on Java side.
    Cache transactions support the following concurrency models:
    • Optimistic - in this mode all cache operations are not distributed to other nodes until Commit(). In this mode one PREPARE message will be sent to participating cache nodes to start acquiring per-transaction locks, and once all nodes reply OK (i.e. Phase 1 completes successfully), a one-way COMMIT message is sent without waiting for reply. If it is necessary to know whenever remote nodes have committed as well, synchronous commit or synchronous rollback should be enabled via CacheConfiguration.setWriteSynchronizationMode.

      Note that in this mode, optimistic failures are only possible in conjunction with Serializable isolation level. In all other cases, optimistic transactions will never fail optimistically and will always be identically ordered on all participating Ignite nodes.

    • Pessimistic - in this mode a lock is acquired on all cache operations with exception of read operations in ReadCommitted mode. All optional filters passed into cache operations will be evaluated after successful lock acquisition. Whenever Commit() is called, a single one-way COMMIT message is sent to participating cache nodes without waiting for reply. Note that there is no reason for distributed PREPARE step, as all locks have been already acquired. Just like with optimistic mode, it is possible to configure synchronous commit or rollback and wait till transaction commits on all participating remote nodes.

    In addition to standard CacheAtomicityMode.TRANSACTIONAL behavior, Ignite also supports a lighter CacheAtomicityMode.ATOMIC mode as well. In this mode distributed transactions and distributed locking are not supported. Disabling transactions and locking allows to achieve much higher performance and throughput ratios. It is recommended that CacheAtomicityMode.TRANSACTIONAL mode is used whenever full ACID-compliant transactions are not needed. You can use cache transactions as follows:

    using (var tx = cache.Ignite.GetTransactions().TxStart())
    {
        int v1 = cache<string, int>.Get("k1");
    
        // Check if v1 satisfies some condition before doing a put.
        if (v1 > 0)
            cache.Put<string, int>("k1", 2);
    
        cache.Remove("k2");
    
        // Commit the transaction.
        tx.Commit();
    }

    ITransactionCollection

    Disposable readonly collection of ITransaction

    ITransactionMetrics

    Transaction metrics, shared across all caches.

    ITransactions

    Transactions facade.

    All members are thread-safe and may be used concurrently from multiple threads.

    Enums

    TransactionConcurrency

    Transaction concurrency control. See ITransaction for more information on transaction concurrency controls.

    TransactionIsolation

    Defines different cache transaction isolation levels. See ITransaction documentation for more information about cache transaction isolation levels.

    TransactionState

    Cache transaction state.

    In This Article
    Back to top © 2015 - 2019 The Apache Software Foundation