Enum IsolationLevel

  • All Implemented Interfaces:
    Serializable, Comparable<IsolationLevel>

    public enum IsolationLevel
    extends Enum<IsolationLevel>
    With the IsolationLevel you have a way to provide declarative control to guarantee isolation between transactions. The transaction is free to provide a higher isolation than the one specified.

    The dirty read isn't added since atm we already have an extremely cheap read using the atomicWeakGet on the refs. Using the atomicWeakGet you have extremely cheap access to committed data.

    The following isolation anomalies have been identified:

    1. Dirty Read
    2. Unrepeatable Read
    3. Inconsistent Read
    4. Write Skew

    Dirty Read

    The DirtyRead isolation anomaly is that one transaction could observe uncommitted changes made by another transaction. The biggest problem with this anomaly is that eventually the updating transaction could abort and the reading transaction sees changes that never made it into the system.

    Currently the Dirty Read anomaly is not possible in Multiverse since writes to main memory are deferred until commit and once the first write to main memory is executed, the following writes are guaranteed to succeed.

    Unrepeatable Read

    The Unrepeatable Read isolation anomaly is that a transaction could see changes made by other transactions. So at one moment it could see value X and a moment later it could see Y. This could lead to all kinds of erratic behavior like transaction that can get stuck in an infinitive loop.

    Such a transaction is called a zombie transaction and can cause serious damage since they are consuming resources (like cpu) and are holding on to various resources (like Locks). So the unrepeatable read should be used with care.

    Inconsistent Read

    With the inconsistent read it is possible that a value is read depending on a previous read value that has been updated by another transaction. E.g. there are 100 refs all initialized with the same value and there is an updating transaction that increments all value's by one, and there is a reading transaction that reads all refs, then it should see the same values for all values.

    Writeskew

    With the writeskew problem it is possible that 2 transactions commit....

    Example 1: there are 1 person that has 2 bank accounts and the invariant is that the sum of both bank accounts is always equal or larger than zero. If user has has 50 euro on both accounts (so the sum is 100) and there are 2 transactions that both subtract 100 euro from the bank accounts, and the first sees account1=50 and account2=50, the subtraction is allowed and subtracts it 100 from the first account, and the second transaction sees exactly the same and subtracts 100 from the second account, it could be possible that the person ends up with -50 on both accounts (so a sum of -100), clearly violating the contract that the the sum should never be smaller than 0.

    Example 2:

    Isolation Levels

    The following isolation levels are currently defined in Multiverse:

    1. Read Committed
    2. Repeatable Read
    3. Snapshot
    4. Serialized
    The read uncommitted is currently not defined since currently there is no need to do a dirty read, there will always be committed data available for reading (the write is deferred till commit, so you won't have to see transactions in progress).

    Implementation and isolation level upgrade

    An implementation of the Txn is free to upgrade the isolation level to a higher one if it doesn't support that specific isolation level. This is the same as Oracle is doing with the ReadUncommitted, which automatically is upgraded to a ReadCommitted or the RepeatableRead which is automatically upgraded to Snapshot (Oracle calls this the Serialized isolation level).

    Isolation: pessimistic or optimistic

    Isolation through locking

    See Also:
    TxnFactoryBuilder.setIsolationLevel(IsolationLevel)
    • Enum Constant Detail

      • RepeatableRead

        public static final IsolationLevel RepeatableRead
        With the RepeatableRead isolation level you will always see committed data and next to that once a read is done, this read is going to be repeatable (so you will see the same value every time).
      • Snapshot

        public static final IsolationLevel Snapshot
        The default isolation level that allows for the writeskew problem but not for dirty or unrepeatable or inconsistent reads.

        This is the 'serialized' isolation level provided by MVCC databases like Oracle/Postgresql (although Postgresql 9 is going to provide a truly serialized isolation level) and MySQL with the InnoDb. All data read. contains committed data and all data will be consistent.

        A transaction that is readonly, gets the same isolation behavior as the Serializable isolation level since the writeskew problem can't occur (nothing can be written).

      • Serializable

        public static final IsolationLevel Serializable
        Provides truly serialized transaction at the cost of reduced performance and concurrency. This is the highest isolation level where no isolation anomalies are allowed to happen. So the writeSkew problem is not allowed to happen.
    • Method Detail

      • values

        public static IsolationLevel[] values()
        Returns an array containing the constants of this enum type, in the order they are declared. This method may be used to iterate over the constants as follows:
        for (IsolationLevel c : IsolationLevel.values())
            System.out.println(c);
        
        Returns:
        an array containing the constants of this enum type, in the order they are declared
      • valueOf

        public static IsolationLevel valueOf​(String name)
        Returns the enum constant of this type with the specified name. The string must match exactly an identifier used to declare an enum constant in this type. (Extraneous whitespace characters are not permitted.)
        Parameters:
        name - the name of the enum constant to be returned.
        Returns:
        the enum constant with the specified name
        Throws:
        IllegalArgumentException - if this enum type has no constant with the specified name
        NullPointerException - if the argument is null
      • doesAllowWriteSkew

        public final boolean doesAllowWriteSkew()
        Checks if the writeskew problem is allowed to happen.
        Returns:
        true if the writeSkew is allowed to happen.
      • doesAllowUnrepeatableRead

        public boolean doesAllowUnrepeatableRead()
        Checks if the dirty read is allowed to happen (so reading data that has not been committed).
        Returns:
        true if the dirty read is allowed to happen.
      • doesAllowInconsistentRead

        public boolean doesAllowInconsistentRead()
        Checks if the inconsistent read is allowed to happen.
        Returns:
        true if the inconsistent read is allowed to happen.