Class: Google::Cloud::Spanner::V1::ReadRequest

Inherits:
Object
  • Object
show all
Extended by:
Protobuf::MessageExts::ClassMethods
Includes:
Protobuf::MessageExts
Defined in:
proto_docs/google/spanner/v1/spanner.rb

Overview

The request for Read and StreamingRead.

Defined Under Namespace

Modules: LockHint, OrderBy

Instance Attribute Summary collapse

Instance Attribute Details

#columns ⇒ ::Array<::String>

Required. The columns of table to be returned for each row matching this request.

Returns:

  • (::Array<::String>) —

    Required. The columns of table to be returned for each row matching this request.



927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
 
# File 'proto_docs/google/spanner/v1/spanner.rb', line 927

class ReadRequest
  include ::Google::Protobuf::MessageExts
  extend ::Google::Protobuf::MessageExts::ClassMethods

  # An option to control the order in which rows are returned from a read.
  module OrderBy
    # Default value.
    #
    # ORDER_BY_UNSPECIFIED is equivalent to ORDER_BY_PRIMARY_KEY.
    ORDER_BY_UNSPECIFIED = 0

    # Read rows are returned in primary key order.
    #
    # In the event that this option is used in conjunction with the
    # `partition_token` field, the API will return an `INVALID_ARGUMENT` error.
    ORDER_BY_PRIMARY_KEY = 1

    # Read rows are returned in any order.
    ORDER_BY_NO_ORDER = 2
  end

  # A lock hint mechanism for reads done within a transaction.
  module LockHint
    # Default value.
    #
    # LOCK_HINT_UNSPECIFIED is equivalent to LOCK_HINT_SHARED.
    LOCK_HINT_UNSPECIFIED = 0

    # 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

    # 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
  end
end

#data_boost_enabled ⇒ ::Boolean

Returns If this is for a partitioned read and this field is set to true, the request is executed with Spanner Data Boost independent compute resources.

If the field is set to true but the request does not set partition_token, the API returns an INVALID_ARGUMENT error.

Returns:

  • (::Boolean) —

    If this is for a partitioned read and this field is set to true, the request is executed with Spanner Data Boost independent compute resources.

    If the field is set to true but the request does not set partition_token, the API returns an INVALID_ARGUMENT error.



927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
 
# File 'proto_docs/google/spanner/v1/spanner.rb', line 927

class ReadRequest
  include ::Google::Protobuf::MessageExts
  extend ::Google::Protobuf::MessageExts::ClassMethods

  # An option to control the order in which rows are returned from a read.
  module OrderBy
    # Default value.
    #
    # ORDER_BY_UNSPECIFIED is equivalent to ORDER_BY_PRIMARY_KEY.
    ORDER_BY_UNSPECIFIED = 0

    # Read rows are returned in primary key order.
    #
    # In the event that this option is used in conjunction with the
    # `partition_token` field, the API will return an `INVALID_ARGUMENT` error.
    ORDER_BY_PRIMARY_KEY = 1

    # Read rows are returned in any order.
    ORDER_BY_NO_ORDER = 2
  end

  # A lock hint mechanism for reads done within a transaction.
  module LockHint
    # Default value.
    #
    # LOCK_HINT_UNSPECIFIED is equivalent to LOCK_HINT_SHARED.
    LOCK_HINT_UNSPECIFIED = 0

    # 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

    # 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
  end
end

#directed_read_options ⇒ ::Google::Cloud::Spanner::V1::DirectedReadOptions

Returns Directed read options for this request.

Returns:



927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
 
# File 'proto_docs/google/spanner/v1/spanner.rb', line 927

class ReadRequest
  include ::Google::Protobuf::MessageExts
  extend ::Google::Protobuf::MessageExts::ClassMethods

  # An option to control the order in which rows are returned from a read.
  module OrderBy
    # Default value.
    #
    # ORDER_BY_UNSPECIFIED is equivalent to ORDER_BY_PRIMARY_KEY.
    ORDER_BY_UNSPECIFIED = 0

    # Read rows are returned in primary key order.
    #
    # In the event that this option is used in conjunction with the
    # `partition_token` field, the API will return an `INVALID_ARGUMENT` error.
    ORDER_BY_PRIMARY_KEY = 1

    # Read rows are returned in any order.
    ORDER_BY_NO_ORDER = 2
  end

  # A lock hint mechanism for reads done within a transaction.
  module LockHint
    # Default value.
    #
    # LOCK_HINT_UNSPECIFIED is equivalent to LOCK_HINT_SHARED.
    LOCK_HINT_UNSPECIFIED = 0

    # 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

    # 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
  end
end

#index ⇒ ::String

Returns If non-empty, the name of an index on table. This index is used instead of the table primary key when interpreting key_set and sorting result rows. See key_set for further information.

Returns:

  • (::String) —

    If non-empty, the name of an index on table. This index is used instead of the table primary key when interpreting key_set and sorting result rows. See key_set for further information.



927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
 
# File 'proto_docs/google/spanner/v1/spanner.rb', line 927

class ReadRequest
  include ::Google::Protobuf::MessageExts
  extend ::Google::Protobuf::MessageExts::ClassMethods

  # An option to control the order in which rows are returned from a read.
  module OrderBy
    # Default value.
    #
    # ORDER_BY_UNSPECIFIED is equivalent to ORDER_BY_PRIMARY_KEY.
    ORDER_BY_UNSPECIFIED = 0

    # Read rows are returned in primary key order.
    #
    # In the event that this option is used in conjunction with the
    # `partition_token` field, the API will return an `INVALID_ARGUMENT` error.
    ORDER_BY_PRIMARY_KEY = 1

    # Read rows are returned in any order.
    ORDER_BY_NO_ORDER = 2
  end

  # A lock hint mechanism for reads done within a transaction.
  module LockHint
    # Default value.
    #
    # LOCK_HINT_UNSPECIFIED is equivalent to LOCK_HINT_SHARED.
    LOCK_HINT_UNSPECIFIED = 0

    # 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

    # 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
  end
end

#key_set ⇒ ::Google::Cloud::Spanner::V1::KeySet

Returns Required. key_set identifies the rows to be yielded. key_set names the primary keys of the rows in table to be yielded, unless index is present. If index is present, then key_set instead names index keys in index.

If the partition_token field is empty, rows are yielded in table primary key order (if index is empty) or index key order (if index is non-empty). If the partition_token field is not empty, rows will be yielded in an unspecified order.

It is not an error for the key_set to name rows that do not exist in the database. Read yields nothing for nonexistent rows.

Returns:

  • (::Google::Cloud::Spanner::V1::KeySet) —

    Required. key_set identifies the rows to be yielded. key_set names the primary keys of the rows in table to be yielded, unless index is present. If index is present, then key_set instead names index keys in index.

    If the partition_token field is empty, rows are yielded in table primary key order (if index is empty) or index key order (if index is non-empty). If the partition_token field is not empty, rows will be yielded in an unspecified order.

    It is not an error for the key_set to name rows that do not exist in the database. Read yields nothing for nonexistent rows.



927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
 
# File 'proto_docs/google/spanner/v1/spanner.rb', line 927

class ReadRequest
  include ::Google::Protobuf::MessageExts
  extend ::Google::Protobuf::MessageExts::ClassMethods

  # An option to control the order in which rows are returned from a read.
  module OrderBy
    # Default value.
    #
    # ORDER_BY_UNSPECIFIED is equivalent to ORDER_BY_PRIMARY_KEY.
    ORDER_BY_UNSPECIFIED = 0

    # Read rows are returned in primary key order.
    #
    # In the event that this option is used in conjunction with the
    # `partition_token` field, the API will return an `INVALID_ARGUMENT` error.
    ORDER_BY_PRIMARY_KEY = 1

    # Read rows are returned in any order.
    ORDER_BY_NO_ORDER = 2
  end

  # A lock hint mechanism for reads done within a transaction.
  module LockHint
    # Default value.
    #
    # LOCK_HINT_UNSPECIFIED is equivalent to LOCK_HINT_SHARED.
    LOCK_HINT_UNSPECIFIED = 0

    # 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

    # 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
  end
end

#limit ⇒ ::Integer

Returns If greater than zero, only the first limit rows are yielded. If limit is zero, the default is no limit. A limit cannot be specified if partition_token is set.

Returns:

  • (::Integer) —

    If greater than zero, only the first limit rows are yielded. If limit is zero, the default is no limit. A limit cannot be specified if partition_token is set.



927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
 
# File 'proto_docs/google/spanner/v1/spanner.rb', line 927

class ReadRequest
  include ::Google::Protobuf::MessageExts
  extend ::Google::Protobuf::MessageExts::ClassMethods

  # An option to control the order in which rows are returned from a read.
  module OrderBy
    # Default value.
    #
    # ORDER_BY_UNSPECIFIED is equivalent to ORDER_BY_PRIMARY_KEY.
    ORDER_BY_UNSPECIFIED = 0

    # Read rows are returned in primary key order.
    #
    # In the event that this option is used in conjunction with the
    # `partition_token` field, the API will return an `INVALID_ARGUMENT` error.
    ORDER_BY_PRIMARY_KEY = 1

    # Read rows are returned in any order.
    ORDER_BY_NO_ORDER = 2
  end

  # A lock hint mechanism for reads done within a transaction.
  module LockHint
    # Default value.
    #
    # LOCK_HINT_UNSPECIFIED is equivalent to LOCK_HINT_SHARED.
    LOCK_HINT_UNSPECIFIED = 0

    # 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

    # 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
  end
end

#lock_hint ⇒ ::Google::Cloud::Spanner::V1::ReadRequest::LockHint

Returns Optional. Lock Hint for the request, it can only be used with read-write transactions.

Returns:



927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
 
# File 'proto_docs/google/spanner/v1/spanner.rb', line 927

class ReadRequest
  include ::Google::Protobuf::MessageExts
  extend ::Google::Protobuf::MessageExts::ClassMethods

  # An option to control the order in which rows are returned from a read.
  module OrderBy
    # Default value.
    #
    # ORDER_BY_UNSPECIFIED is equivalent to ORDER_BY_PRIMARY_KEY.
    ORDER_BY_UNSPECIFIED = 0

    # Read rows are returned in primary key order.
    #
    # In the event that this option is used in conjunction with the
    # `partition_token` field, the API will return an `INVALID_ARGUMENT` error.
    ORDER_BY_PRIMARY_KEY = 1

    # Read rows are returned in any order.
    ORDER_BY_NO_ORDER = 2
  end

  # A lock hint mechanism for reads done within a transaction.
  module LockHint
    # Default value.
    #
    # LOCK_HINT_UNSPECIFIED is equivalent to LOCK_HINT_SHARED.
    LOCK_HINT_UNSPECIFIED = 0

    # 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

    # 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
  end
end

#order_by ⇒ ::Google::Cloud::Spanner::V1::ReadRequest::OrderBy

Optional. Order for the returned rows.

By default, Spanner will return result rows in primary key order except for PartitionRead requests. For applications that do not require rows to be returned in primary key (ORDER_BY_PRIMARY_KEY) order, setting ORDER_BY_NO_ORDER option allows Spanner to optimize row retrieval, resulting in lower latencies in certain cases (e.g. bulk point lookups).

Returns:

  • (::Google::Cloud::Spanner::V1::ReadRequest::OrderBy) —

    Optional. Order for the returned rows.

    By default, Spanner will return result rows in primary key order except for PartitionRead requests. For applications that do not require rows to be returned in primary key (ORDER_BY_PRIMARY_KEY) order, setting ORDER_BY_NO_ORDER option allows Spanner to optimize row retrieval, resulting in lower latencies in certain cases (e.g. bulk point lookups).



927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
 
# File 'proto_docs/google/spanner/v1/spanner.rb', line 927

class ReadRequest
  include ::Google::Protobuf::MessageExts
  extend ::Google::Protobuf::MessageExts::ClassMethods

  # An option to control the order in which rows are returned from a read.
  module OrderBy
    # Default value.
    #
    # ORDER_BY_UNSPECIFIED is equivalent to ORDER_BY_PRIMARY_KEY.
    ORDER_BY_UNSPECIFIED = 0

    # Read rows are returned in primary key order.
    #
    # In the event that this option is used in conjunction with the
    # `partition_token` field, the API will return an `INVALID_ARGUMENT` error.
    ORDER_BY_PRIMARY_KEY = 1

    # Read rows are returned in any order.
    ORDER_BY_NO_ORDER = 2
  end

  # A lock hint mechanism for reads done within a transaction.
  module LockHint
    # Default value.
    #
    # LOCK_HINT_UNSPECIFIED is equivalent to LOCK_HINT_SHARED.
    LOCK_HINT_UNSPECIFIED = 0

    # 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

    # 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
  end
end

#partition_token ⇒ ::String

Returns If present, results will be restricted to the specified partition previously created using PartitionRead(). There must be an exact match for the values of fields common to this message and the PartitionReadRequest message used to create this partition_token.

Returns:

  • (::String) —

    If present, results will be restricted to the specified partition previously created using PartitionRead(). There must be an exact match for the values of fields common to this message and the PartitionReadRequest message used to create this partition_token.



927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
 
# File 'proto_docs/google/spanner/v1/spanner.rb', line 927

class ReadRequest
  include ::Google::Protobuf::MessageExts
  extend ::Google::Protobuf::MessageExts::ClassMethods

  # An option to control the order in which rows are returned from a read.
  module OrderBy
    # Default value.
    #
    # ORDER_BY_UNSPECIFIED is equivalent to ORDER_BY_PRIMARY_KEY.
    ORDER_BY_UNSPECIFIED = 0

    # Read rows are returned in primary key order.
    #
    # In the event that this option is used in conjunction with the
    # `partition_token` field, the API will return an `INVALID_ARGUMENT` error.
    ORDER_BY_PRIMARY_KEY = 1

    # Read rows are returned in any order.
    ORDER_BY_NO_ORDER = 2
  end

  # A lock hint mechanism for reads done within a transaction.
  module LockHint
    # Default value.
    #
    # LOCK_HINT_UNSPECIFIED is equivalent to LOCK_HINT_SHARED.
    LOCK_HINT_UNSPECIFIED = 0

    # 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

    # 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
  end
end

#request_options ⇒ ::Google::Cloud::Spanner::V1::RequestOptions

Returns Common options for this request.

Returns:



927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
 
# File 'proto_docs/google/spanner/v1/spanner.rb', line 927

class ReadRequest
  include ::Google::Protobuf::MessageExts
  extend ::Google::Protobuf::MessageExts::ClassMethods

  # An option to control the order in which rows are returned from a read.
  module OrderBy
    # Default value.
    #
    # ORDER_BY_UNSPECIFIED is equivalent to ORDER_BY_PRIMARY_KEY.
    ORDER_BY_UNSPECIFIED = 0

    # Read rows are returned in primary key order.
    #
    # In the event that this option is used in conjunction with the
    # `partition_token` field, the API will return an `INVALID_ARGUMENT` error.
    ORDER_BY_PRIMARY_KEY = 1

    # Read rows are returned in any order.
    ORDER_BY_NO_ORDER = 2
  end

  # A lock hint mechanism for reads done within a transaction.
  module LockHint
    # Default value.
    #
    # LOCK_HINT_UNSPECIFIED is equivalent to LOCK_HINT_SHARED.
    LOCK_HINT_UNSPECIFIED = 0

    # 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

    # 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
  end
end

#resume_token ⇒ ::String

Returns If this request is resuming a previously interrupted read, resume_token should be copied from the last PartialResultSet yielded before the interruption. Doing this enables the new read to resume where the last read left off. The rest of the request parameters must exactly match the request that yielded this token.

Returns:

  • (::String) —

    If this request is resuming a previously interrupted read, resume_token should be copied from the last PartialResultSet yielded before the interruption. Doing this enables the new read to resume where the last read left off. The rest of the request parameters must exactly match the request that yielded this token.



927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
 
# File 'proto_docs/google/spanner/v1/spanner.rb', line 927

class ReadRequest
  include ::Google::Protobuf::MessageExts
  extend ::Google::Protobuf::MessageExts::ClassMethods

  # An option to control the order in which rows are returned from a read.
  module OrderBy
    # Default value.
    #
    # ORDER_BY_UNSPECIFIED is equivalent to ORDER_BY_PRIMARY_KEY.
    ORDER_BY_UNSPECIFIED = 0

    # Read rows are returned in primary key order.
    #
    # In the event that this option is used in conjunction with the
    # `partition_token` field, the API will return an `INVALID_ARGUMENT` error.
    ORDER_BY_PRIMARY_KEY = 1

    # Read rows are returned in any order.
    ORDER_BY_NO_ORDER = 2
  end

  # A lock hint mechanism for reads done within a transaction.
  module LockHint
    # Default value.
    #
    # LOCK_HINT_UNSPECIFIED is equivalent to LOCK_HINT_SHARED.
    LOCK_HINT_UNSPECIFIED = 0

    # 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

    # 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
  end
end

#session ⇒ ::String

Returns Required. The session in which the read should be performed.

Returns:

  • (::String) —

    Required. The session in which the read should be performed.



927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
 
# File 'proto_docs/google/spanner/v1/spanner.rb', line 927

class ReadRequest
  include ::Google::Protobuf::MessageExts
  extend ::Google::Protobuf::MessageExts::ClassMethods

  # An option to control the order in which rows are returned from a read.
  module OrderBy
    # Default value.
    #
    # ORDER_BY_UNSPECIFIED is equivalent to ORDER_BY_PRIMARY_KEY.
    ORDER_BY_UNSPECIFIED = 0

    # Read rows are returned in primary key order.
    #
    # In the event that this option is used in conjunction with the
    # `partition_token` field, the API will return an `INVALID_ARGUMENT` error.
    ORDER_BY_PRIMARY_KEY = 1

    # Read rows are returned in any order.
    ORDER_BY_NO_ORDER = 2
  end

  # A lock hint mechanism for reads done within a transaction.
  module LockHint
    # Default value.
    #
    # LOCK_HINT_UNSPECIFIED is equivalent to LOCK_HINT_SHARED.
    LOCK_HINT_UNSPECIFIED = 0

    # 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

    # 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
  end
end

#table ⇒ ::String

Returns Required. The name of the table in the database to be read.

Returns:

  • (::String) —

    Required. The name of the table in the database to be read.



927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
 
# File 'proto_docs/google/spanner/v1/spanner.rb', line 927

class ReadRequest
  include ::Google::Protobuf::MessageExts
  extend ::Google::Protobuf::MessageExts::ClassMethods

  # An option to control the order in which rows are returned from a read.
  module OrderBy
    # Default value.
    #
    # ORDER_BY_UNSPECIFIED is equivalent to ORDER_BY_PRIMARY_KEY.
    ORDER_BY_UNSPECIFIED = 0

    # Read rows are returned in primary key order.
    #
    # In the event that this option is used in conjunction with the
    # `partition_token` field, the API will return an `INVALID_ARGUMENT` error.
    ORDER_BY_PRIMARY_KEY = 1

    # Read rows are returned in any order.
    ORDER_BY_NO_ORDER = 2
  end

  # A lock hint mechanism for reads done within a transaction.
  module LockHint
    # Default value.
    #
    # LOCK_HINT_UNSPECIFIED is equivalent to LOCK_HINT_SHARED.
    LOCK_HINT_UNSPECIFIED = 0

    # 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

    # 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
  end
end

#transaction ⇒ ::Google::Cloud::Spanner::V1::TransactionSelector

Returns The transaction to use. If none is provided, the default is a temporary read-only transaction with strong concurrency.

Returns:



927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
 
# File 'proto_docs/google/spanner/v1/spanner.rb', line 927

class ReadRequest
  include ::Google::Protobuf::MessageExts
  extend ::Google::Protobuf::MessageExts::ClassMethods

  # An option to control the order in which rows are returned from a read.
  module OrderBy
    # Default value.
    #
    # ORDER_BY_UNSPECIFIED is equivalent to ORDER_BY_PRIMARY_KEY.
    ORDER_BY_UNSPECIFIED = 0

    # Read rows are returned in primary key order.
    #
    # In the event that this option is used in conjunction with the
    # `partition_token` field, the API will return an `INVALID_ARGUMENT` error.
    ORDER_BY_PRIMARY_KEY = 1

    # Read rows are returned in any order.
    ORDER_BY_NO_ORDER = 2
  end

  # A lock hint mechanism for reads done within a transaction.
  module LockHint
    # Default value.
    #
    # LOCK_HINT_UNSPECIFIED is equivalent to LOCK_HINT_SHARED.
    LOCK_HINT_UNSPECIFIED = 0

    # 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

    # 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
  end
end