Skip to content

Commit 5937595

Browse files
committed
fix: update README to include isolation level repeatable read
The README file did not include any information about REPEATABLE READ.
1 parent b94ceb6 commit 5937595

File tree

1 file changed

+15
-7
lines changed

1 file changed

+15
-7
lines changed

README.rst

Lines changed: 15 additions & 7 deletions
Original file line numberDiff line numberDiff line change
@@ -89,7 +89,8 @@ To pass your custom client object directly to be be used, create engine as follo
8989
9090
engine = create_engine(
9191
"spanner+spanner:///projects/project-id/instances/instance-id/databases/database-id",
92-
connect_args={'client': spanner.Client(project="project-id")}
92+
connect_args={'client': spanner.Client(project="project-id")},
93+
isolation_level="SERIALIZABLE"
9394
)
9495
9596
Create a table
@@ -264,8 +265,9 @@ Create a UNIQUE index:
264265
Autocommit mode
265266
~~~~~~~~~~~~~~~
266267

267-
Spanner dialect supports both ``SERIALIZABLE`` and ``AUTOCOMMIT``
268-
isolation levels. ``SERIALIZABLE`` is the default isolation level.
268+
Spanner dialect supports ``SERIALIZABLE``, ``REPEATABLE_READ``, and
269+
``AUTOCOMMIT`` isolation levels. ``SERIALIZABLE`` is the default
270+
isolation level.
269271

270272
``AUTOCOMMIT`` mode corresponds to automatically committing each
271273
insert/update/delete statement right after is has been executed.
@@ -287,11 +289,17 @@ Isolation level change example:
287289
288290
Automatic transaction retry
289291
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
290-
In the default ``SERIALIZABLE`` mode transactions may fail with ``Aborted`` exception. This is a transient kind of errors, which mostly happen to prevent data corruption by concurrent modifications. Though the original transaction becomes non operational, a simple retry of the queries solves the issue.
292+
In ``SERIALIZABLE`` isolation mode, transactions may fail with an ``Aborted`` exception.
293+
This happens if there are conflicts between different transactions, for example if one
294+
transaction tries to read data that another transaction has modified. Aborted transactions
295+
should be retried by the client. The Spanner SQLAlchemy provider automatically retries
296+
aborted transactions.
291297

292-
This, however, may require to manually repeat a long list of operations, executed in the failed transaction. To simplify it, Spanner Connection API tracks all the operations, executed inside current transaction, and their result checksums. If the transaction failed with ``Aborted`` exception, the Connection API will automatically start a new transaction and will re-run all the tracked operations, checking if their results are the same as they were in the original transaction. In case data changed, and results differ, the transaction is dropped, as there is no way to automatically retry it.
298+
Isolation level ``SERIALIZABLE`` takes lock for both **reads and writes**.
293299

294-
In ``AUTOCOMMIT`` mode automatic transactions retry mechanism is disabled, as every operation is committed just in time, and there is no way an ``Aborted`` exception can happen.
300+
Use isolation level ``REPEATABLE READ`` to reduce the amount of locks that
301+
are taken by read/write transactions. ``REPEATABLE READ`` only takes locks
302+
for **writes** and for queries that use a ``FOR UPDATE`` clause.
295303

296304
Auto-increment primary keys
297305
~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -340,7 +348,7 @@ Usage example:
340348
query = query.filter(User.name.in_(["val1", "val2"]))
341349
query.statement.compile(session.bind)
342350
343-
ReadOnly transactions
351+
Read-only transactions
344352
~~~~~~~~~~~~~~~~~~~~~
345353

346354
By default, transactions produced by a Spanner connection are in

0 commit comments

Comments
 (0)