Enum ReadRequest.LockHint (6.74.1)

Version 6.74.1

• 6.80.1 (latest)
• 6.79.0
• 6.77.0
• 6.74.1
• 6.72.0
• 6.71.0
• 6.69.0
• 6.68.0
• 6.66.0
• 6.65.1
• 6.62.0
• 6.60.0
• 6.58.0
• 6.57.0
• 6.56.0
• 6.55.0
• 6.54.0
• 6.53.0
• 6.52.1
• 6.51.0
• 6.50.1
• 6.49.0
• 6.25.1
• 6.24.0
• 6.23.4
• 6.22.0
• 6.21.2
• 6.20.0
• 6.19.1
• 6.18.0
• 6.17.4
• 6.14.1

public enum ReadRequest.LockHint extends Enum<ReadRequest.LockHint> implements ProtocolMessageEnum

A lock hint mechanism for reads done within a transaction.

Protobuf enum google.spanner.v1.ReadRequest.LockHint

Implements

ProtocolMessageEnum

Inherited Members

Enum.<T>valueOf(Class<T>,String)

Enum.clone()

Enum.compareTo(E)

Enum.equals(Object)

Enum.finalize()

Enum.getDeclaringClass()

Enum.hashCode()

Enum.name()

Enum.ordinal()

Enum.toString()

Object.getClass()

Object.notify()

Object.notifyAll()

Object.wait()

Object.wait(long)

Object.wait(long,int)

Static Fields
Name	Description
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;
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;
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. LOCK_HINT_SHARED = 1;
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. LOCK_HINT_SHARED = 1;
LOCK_HINT_UNSPECIFIED	Default value. LOCK_HINT_UNSPECIFIED is equivalent to LOCK_HINT_SHARED. LOCK_HINT_UNSPECIFIED = 0;
LOCK_HINT_UNSPECIFIED_VALUE	Default value. LOCK_HINT_UNSPECIFIED is equivalent to LOCK_HINT_SHARED. LOCK_HINT_UNSPECIFIED = 0;
UNRECOGNIZED

Static Methods
Name	Description
forNumber(int value)
getDescriptor()
internalGetValueMap()
valueOf(Descriptors.EnumValueDescriptor desc)
valueOf(int value)	Deprecated. Use #forNumber(int) instead.
valueOf(String name)
values()

Methods
Name	Description
getDescriptorForType()
getNumber()
getValueDescriptor()