Transaction

It is crucial to correctly manage transactions in an asynchronous program, because you never know how much time an await will actually wait for, it will cause disasters if transactions are on hold for too long. GINO enforces explicit transaction management to help dealing with it.

Basic usage

Transactions belong to GinoConnection. The most common way to use transactions is through an async with statement:

  1. async with connection.transaction() as tx:
  2.     await connection.status('INSERT INTO mytable VALUES(1, 2, 3)')

This guarantees a transaction is opened when entering the async with block, and closed when exiting the block - committed if exits normally, or rolled back by exception. The underlying transaction instance from the database driver is available at raw_transaction, but in most cases you don’t need to touch it.

GINO provides two convenient shortcuts to end the transaction early:

They will raise an internal exception to correspondingly commit or rollback the transaction, thus the code within the async with block after raise_commit() or raise_rollback() is skipped. The internal exception is inherited from BaseException so that normal try ... except Exception block can’t trap it. This exception stops propagating at the end of async with block, so you don’t need to worry about handling it.

Transactions can also be started on a GinoEngine:

  1. async with engine.transaction() as tx:
  2.     await engine.status('INSERT INTO mytable VALUES(1, 2, 3)')

Here a GinoConnection is borrowed implicitly before entering the transaction, and guaranteed to be returned after transaction is done. The GinoConnection instance is accessible at tx.connection. Other than that, everything else is the same.

重要

The implicit connection is by default borrowed with reuse=True. That means using transaction() of GinoEngine within a connection context is the same as calling transaction() of the current connection without having to reference it, no separate connection shall be created.

Similarly, if your Gino instance has a bind, you may also do the same on it:

  1. async with db.transaction() as tx:
  2.     await db.status('INSERT INTO mytable VALUES(1, 2, 3)')

Nested Transactions

Transactions can be nested, nested transaction will create a savepoint as for now on asyncpg. A similar example from asyncpg doc:

  1. async with connection.transaction() as tx1:
  2.     await connection.status('CREATE TABLE mytab (a int)')
  4.     # Create a nested transaction:
  5.     async with connection.transaction() as tx2:
  6.         await connection.status('INSERT INTO mytab (a) VALUES (1), (2)')
  7.         # Rollback the nested transaction:
  8.         tx2.raise_rollback()
  10.     # Because the nested transaction was rolled back, there
  11.     # will be nothing in `mytab`.
  12.     assert await connection.all('SELECT a FROM mytab') == []

As you can see, the raise_rollback() breaks only the async with block of the specified tx2, the outer transaction tx1 just continued. What if we break the outer transaction from within the inner transaction? The inner transaction context won’t trap the internal exception because it recognizes the exception is not created upon itself. Instead, the inner transaction context only follows the behavior to either commit or rollback, and lets the exception propagate.

Because of the default reusing behavior, transactions on engine or db follows the same nesting rules. Please see GinoTransaction for more information.

Manual Control

Other than using async with, you can also manually control the transaction:

  1. tx = await connection.transaction()
  2. try:
  3.     await db.status('INSERT INTO mytable VALUES(1, 2, 3)')
  4.     await tx.commit()
  5. except Exception:
  6.     await tx.rollback()
  7.     raise

You can’t use raise_commit() or raise_rollback() here, similarly it is prohibited to use commit() and rollback() in an async with block.