Enum ReadRequest.LockHint

java.lang.Object
java.lang.Enum<ReadRequest.LockHint>
com.google.spanner.v1.ReadRequest.LockHint
All Implemented Interfaces:
com.google.protobuf.Internal.EnumLite, com.google.protobuf.ProtocolMessageEnum, Serializable, Comparable<ReadRequest.LockHint>
Enclosing class:
ReadRequest

public static enum ReadRequest.LockHint extends Enum<ReadRequest.LockHint> implements com.google.protobuf.ProtocolMessageEnum
 A lock hint mechanism for reads done within a transaction.
 
Protobuf enum google.spanner.v1.ReadRequest.LockHint
  • Enum Constant Details

    • LOCK_HINT_UNSPECIFIED

      public static final ReadRequest.LockHint LOCK_HINT_UNSPECIFIED
       Default value.
      
       LOCK_HINT_UNSPECIFIED is equivalent to LOCK_HINT_SHARED.
       
      LOCK_HINT_UNSPECIFIED = 0;
    • LOCK_HINT_SHARED

      public static final ReadRequest.LockHint LOCK_HINT_SHARED
       Acquire shared locks.
      
       By default when you perform a read as part of a read-write transaction,
       Spanner acquires shared read locks, which allows other reads to still
       access the data until your transaction is ready to commit. When your
       transaction is committing and writes are being applied, the transaction
       attempts to upgrade to an exclusive lock for any data you are writing.
       For more information about locks, see [Lock
       modes](https://cloud.google.com/spanner/docs/introspection/lock-statistics#explain-lock-modes).
       
      LOCK_HINT_SHARED = 1;
    • LOCK_HINT_EXCLUSIVE

      public static final ReadRequest.LockHint LOCK_HINT_EXCLUSIVE
       Acquire exclusive locks.
      
       Requesting exclusive locks is beneficial if you observe high write
       contention, which means you notice that multiple transactions are
       concurrently trying to read and write to the same data, resulting in a
       large number of aborts. This problem occurs when two transactions
       initially acquire shared locks and then both try to upgrade to exclusive
       locks at the same time. In this situation both transactions are waiting
       for the other to give up their lock, resulting in a deadlocked situation.
       Spanner is able to detect this occurring and force one of the
       transactions to abort. However, this is a slow and expensive operation
       and results in lower performance. In this case it makes sense to acquire
       exclusive locks at the start of the transaction because then when
       multiple transactions try to act on the same data, they automatically get
       serialized. Each transaction waits its turn to acquire the lock and
       avoids getting into deadlock situations.
      
       Because the exclusive lock hint is just a hint, it should not be
       considered equivalent to a mutex. In other words, you should not use
       Spanner exclusive locks as a mutual exclusion mechanism for the execution
       of code outside of Spanner.
      
       **Note:** Request exclusive locks judiciously because they block others
       from reading that data for the entire transaction, rather than just when
       the writes are being performed. Unless you observe high write contention,
       you should use the default of shared read locks so you don't prematurely
       block other clients from reading the data that you're writing to.
       
      LOCK_HINT_EXCLUSIVE = 2;
    • UNRECOGNIZED

      public static final ReadRequest.LockHint UNRECOGNIZED
  • Field Details

    • LOCK_HINT_UNSPECIFIED_VALUE

      public static final int LOCK_HINT_UNSPECIFIED_VALUE
       Default value.
      
       LOCK_HINT_UNSPECIFIED is equivalent to LOCK_HINT_SHARED.
       
      LOCK_HINT_UNSPECIFIED = 0;
      See Also:
    • LOCK_HINT_SHARED_VALUE

      public static final int LOCK_HINT_SHARED_VALUE
       Acquire shared locks.
      
       By default when you perform a read as part of a read-write transaction,
       Spanner acquires shared read locks, which allows other reads to still
       access the data until your transaction is ready to commit. When your
       transaction is committing and writes are being applied, the transaction
       attempts to upgrade to an exclusive lock for any data you are writing.
       For more information about locks, see [Lock
       modes](https://cloud.google.com/spanner/docs/introspection/lock-statistics#explain-lock-modes).
       
      LOCK_HINT_SHARED = 1;
      See Also:
    • LOCK_HINT_EXCLUSIVE_VALUE

      public static final int LOCK_HINT_EXCLUSIVE_VALUE
       Acquire exclusive locks.
      
       Requesting exclusive locks is beneficial if you observe high write
       contention, which means you notice that multiple transactions are
       concurrently trying to read and write to the same data, resulting in a
       large number of aborts. This problem occurs when two transactions
       initially acquire shared locks and then both try to upgrade to exclusive
       locks at the same time. In this situation both transactions are waiting
       for the other to give up their lock, resulting in a deadlocked situation.
       Spanner is able to detect this occurring and force one of the
       transactions to abort. However, this is a slow and expensive operation
       and results in lower performance. In this case it makes sense to acquire
       exclusive locks at the start of the transaction because then when
       multiple transactions try to act on the same data, they automatically get
       serialized. Each transaction waits its turn to acquire the lock and
       avoids getting into deadlock situations.
      
       Because the exclusive lock hint is just a hint, it should not be
       considered equivalent to a mutex. In other words, you should not use
       Spanner exclusive locks as a mutual exclusion mechanism for the execution
       of code outside of Spanner.
      
       **Note:** Request exclusive locks judiciously because they block others
       from reading that data for the entire transaction, rather than just when
       the writes are being performed. Unless you observe high write contention,
       you should use the default of shared read locks so you don't prematurely
       block other clients from reading the data that you're writing to.
       
      LOCK_HINT_EXCLUSIVE = 2;
      See Also:
  • Method Details

    • values

      public static ReadRequest.LockHint[] values()
      Returns an array containing the constants of this enum type, in the order they are declared.
      Returns:
      an array containing the constants of this enum type, in the order they are declared
    • valueOf

      public static ReadRequest.LockHint 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
    • getNumber

      public final int getNumber()
      Specified by:
      getNumber in interface com.google.protobuf.Internal.EnumLite
      Specified by:
      getNumber in interface com.google.protobuf.ProtocolMessageEnum
    • valueOf

      @Deprecated public static ReadRequest.LockHint valueOf(int value)
      Deprecated.
      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:
      value - 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
    • forNumber

      public static ReadRequest.LockHint forNumber(int value)
      Parameters:
      value - The numeric wire value of the corresponding enum entry.
      Returns:
      The enum associated with the given numeric wire value.
    • internalGetValueMap

      public static com.google.protobuf.Internal.EnumLiteMap<ReadRequest.LockHint> internalGetValueMap()
    • getValueDescriptor

      public final com.google.protobuf.Descriptors.EnumValueDescriptor getValueDescriptor()
      Specified by:
      getValueDescriptor in interface com.google.protobuf.ProtocolMessageEnum
    • getDescriptorForType

      public final com.google.protobuf.Descriptors.EnumDescriptor getDescriptorForType()
      Specified by:
      getDescriptorForType in interface com.google.protobuf.ProtocolMessageEnum
    • getDescriptor

      public static final com.google.protobuf.Descriptors.EnumDescriptor getDescriptor()
    • valueOf

      public static ReadRequest.LockHint valueOf(com.google.protobuf.Descriptors.EnumValueDescriptor desc)
      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:
      desc - 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