Transactions and Connection Management

Managing Transactions

Changed in version 1.4: Session transaction management has been revised to be clearer and easier to use. In particular, it now features “autobegin” operation, which means the point at which a transaction begins may be controlled, without using the legacy “autocommit” mode.

The Session tracks the state of a single “virtual” transaction at a time, using an object called SessionTransaction. This object then makes use of the underlying Engine or engines to which the Session object is bound in order to start real connection-level transactions using the Connection object as needed.

This “virtual” transaction is created automatically when needed, or can alternatively be started using the Session.begin() method. To as great a degree as possible, Python context manager use is supported both at the level of creating Session objects as well as to maintain the scope of the SessionTransaction.

Below, assume we start with a Session:

  1. from sqlalchemy.orm import Session
  3. session = Session(engine)

We can now run operations within a demarcated transaction using a context manager:

  1. with session.begin():
  2.     session.add(some_object())
  3.     session.add(some_other_object())
  4. # commits transaction at the end, or rolls back if there
  5. # was an exception raised

At the end of the above context, assuming no exceptions were raised, any pending objects will be flushed to the database and the database transaction will be committed. If an exception was raised within the above block, then the transaction would be rolled back. In both cases, the above Session subsequent to exiting the block is ready to be used in subsequent transactions.

The Session.begin() method is optional, and the Session may also be used in a commit-as-you-go approach, where it will begin transactions automatically as needed; these only need be committed or rolled back:

  1. session = Session(engine)
  3. session.add(some_object())
  4. session.add(some_other_object())
  6. session.commit()  # commits
  8. # will automatically begin again
  9. result = session.execute("< some select statement >")
  10. session.add_all([more_objects, ...])
  11. session.commit()  # commits
  13. session.add(still_another_object)
  14. session.flush()  # flush still_another_object
  15. session.rollback()  # rolls back still_another_object

The Session itself features a Session.close() method. If the Session is begun within a transaction that has not yet been committed or rolled back, this method will cancel (i.e. rollback) that transaction, and also expunge all objects contained within the Session object’s state. If the Session is being used in such a way that a call to Session.commit() or Session.rollback() is not guaranteed (e.g. not within a context manager or similar), the close method may be used to ensure all resources are released:

  1. # expunges all objects, releases all transactions unconditionally
  2. # (with rollback), releases all database connections back to their
  3. # engines
  4. session.close()

Finally, the session construction / close process can itself be run via context manager. This is the best way to ensure that the scope of a Session object’s use is scoped within a fixed block. Illustrated via the Session constructor first:

  1. with Session(engine) as session:
  2.     session.add(some_object())
  3.     session.add(some_other_object())
  5.     session.commit()  # commits
  7.     session.add(still_another_object)
  8.     session.flush()  # flush still_another_object
  10.     session.commit()  # commits
  12.     result = session.execute("<some SELECT statement>")
  14. # remaining transactional state from the .execute() call is
  15. # discarded

Similarly, the sessionmaker can be used in the same way:

  1. Session = sessionmaker(engine)
  3. with Session() as session:
  4.     with session.begin():
  5.         session.add(some_object)
  6.     # commits
  8. # closes the Session

sessionmaker itself includes a sessionmaker.begin() method to allow both operations to take place at once:

  1. with Session.begin() as session:
  2.     session.add(some_object)

Using SAVEPOINT

SAVEPOINT transactions, if supported by the underlying engine, may be delineated using the Session.begin_nested() method:

  1. Session = sessionmaker()
  3. with Session.begin() as session:
  4.     session.add(u1)
  5.     session.add(u2)
  7.     nested = session.begin_nested()  # establish a savepoint
  8.     session.add(u3)
  9.     nested.rollback()  # rolls back u3, keeps u1 and u2
  11. # commits u1 and u2

Each time Session.begin_nested() is called, a new “BEGIN SAVEPOINT” command is emitted to the database within the scope of the current database transaction (starting one if not already in progress), and an object of type SessionTransaction is returned, which represents a handle to this SAVEPOINT. When the .commit() method on this object is called, “RELEASE SAVEPOINT” is emitted to the database, and if instead the .rollback() method is called, “ROLLBACK TO SAVEPOINT” is emitted. The enclosing database transaction remains in progress.

Session.begin_nested() is typically used as a context manager where specific per-instance errors may be caught, in conjunction with a rollback emitted for that portion of the transaction’s state, without rolling back the whole transaction, as in the example below:

  1. for record in records:
  2.     try:
  3.         with session.begin_nested():
  4.             session.merge(record)
  5.     except:
  6.         print("Skipped record %s" % record)
  7. session.commit()

When the context manager yielded by Session.begin_nested() completes, it “commits” the savepoint, which includes the usual behavior of flushing all pending state. When an error is raised, the savepoint is rolled back and the state of the Session local to the objects that were changed is expired.

This pattern is ideal for situations such as using PostgreSQL and catching IntegrityError to detect duplicate rows; PostgreSQL normally aborts the entire tranasction when such an error is raised, however when using SAVEPOINT, the outer transaction is maintained. In the example below a list of data is persisted into the database, with the occasional “duplicate primary key” record skipped, without rolling back the entire operation:

  1. from sqlalchemy import exc
  3. with session.begin():
  4.     for record in records:
  5.         try:
  6.             with session.begin_nested():
  7.                 obj = SomeRecord(id=record["identifier"], name=record["name"])
  8.                 session.add(obj)
  9.         except exc.IntegrityError:
  10.             print(f"Skipped record {record} - row already exists")

When Session.begin_nested() is called, the Session first flushes all currently pending state to the database; this occurs unconditionally, regardless of the value of the Session.autoflush parameter which normally may be used to disable automatic flush. The rationale for this behavior is so that when a rollback on this nested transaction occurs, the Session may expire any in-memory state that was created within the scope of the SAVEPOINT, while ensuring that when those expired objects are refreshed, the state of the object graph prior to the beginning of the SAVEPOINT will be available to re-load from the database.

In modern versions of SQLAlchemy, when a SAVEPOINT initiated by Session.begin_nested() is rolled back, in-memory object state that was modified since the SAVEPOINT was created is expired, however other object state that was not altered since the SAVEPOINT began is maintained. This is so that subsequent operations can continue to make use of the otherwise unaffected data without the need for refreshing it from the database.

See also

Connection.begin_nested() - Core SAVEPOINT API

Session-level vs. Engine level transaction control

The Connection in Core and _session.Session in ORM feature equivalent transactional semantics, both at the level of the sessionmaker vs. the Engine, as well as the Session vs. the Connection. The following sections detail these scenarios based on the following scheme:

  1. ORM                                           Core
  2. -----------------------------------------     -----------------------------------
  3. sessionmaker                                  Engine
  4. Session                                       Connection
  5. sessionmaker.begin()                          Engine.begin()
  6. some_session.commit()                         some_connection.commit()
  7. with some_sessionmaker() as session:          with some_engine.connect() as conn:
  8. with some_sessionmaker.begin() as session:    with some_engine.begin() as conn:
  9. with some_session.begin_nested() as sp:       with some_connection.begin_nested() as sp:

Commit as you go

Both Session and Connection feature Connection.commit() and Connection.rollback() methods. Using SQLAlchemy 2.0-style operation, these methods affect the outermost transaction in all cases. For the Session, it is assumed that Session.autobegin is left at its default value of True.

Engine:

  1. engine = create_engine("postgresql+psycopg2://user:pass@host/dbname")
  3. with engine.connect() as conn:
  4.     conn.execute(
  5.         some_table.insert(),
  6.         [
  7.             {"data": "some data one"},
  8.             {"data": "some data two"},
  9.             {"data": "some data three"},
  10.         ],
  11.     )
  12.     conn.commit()

Session:

  1. Session = sessionmaker(engine)
  3. with Session() as session:
  4.     session.add_all(
  5.         [
  6.             SomeClass(data="some data one"),
  7.             SomeClass(data="some data two"),
  8.             SomeClass(data="some data three"),
  9.         ]
  10.     )
  11.     session.commit()

Begin Once

Both sessionmaker and Engine feature a Engine.begin() method that will both procure a new object with which to execute SQL statements (the Session and Connection, respectively) and then return a context manager that will maintain a begin/commit/rollback context for that object.

Engine:

  1. engine = create_engine("postgresql+psycopg2://user:pass@host/dbname")
  3. with engine.begin() as conn:
  4.     conn.execute(
  5.         some_table.insert(),
  6.         [
  7.             {"data": "some data one"},
  8.             {"data": "some data two"},
  9.             {"data": "some data three"},
  10.         ],
  11.     )
  12. # commits and closes automatically

Session:

  1. Session = sessionmaker(engine)
  3. with Session.begin() as session:
  4.     session.add_all(
  5.         [
  6.             SomeClass(data="some data one"),
  7.             SomeClass(data="some data two"),
  8.             SomeClass(data="some data three"),
  9.         ]
  10.     )
  11. # commits and closes automatically

Nested Transaction

When using a SAVEPOINT via the Session.begin_nested() or Connection.begin_nested() methods, the transaction object returned must be used to commit or rollback the SAVEPOINT. Calling the Session.commit() or Connection.commit() methods will always commit the outermost transaction; this is a SQLAlchemy 2.0 specific behavior that is reversed from the 1.x series.

Engine:

  1. engine = create_engine("postgresql+psycopg2://user:pass@host/dbname")
  3. with engine.begin() as conn:
  4.     savepoint = conn.begin_nested()
  5.     conn.execute(
  6.         some_table.insert(),
  7.         [
  8.             {"data": "some data one"},
  9.             {"data": "some data two"},
  10.             {"data": "some data three"},
  11.         ],
  12.     )
  13.     savepoint.commit()  # or rollback
  15. # commits automatically

Session:

  1. Session = sessionmaker(engine)
  3. with Session.begin() as session:
  4.     savepoint = session.begin_nested()
  5.     session.add_all(
  6.         [
  7.             SomeClass(data="some data one"),
  8.             SomeClass(data="some data two"),
  9.             SomeClass(data="some data three"),
  10.         ]
  11.     )
  12.     savepoint.commit()  # or rollback
  13. # commits automatically

Explicit Begin

The Session features “autobegin” behavior, meaning that as soon as operations begin to take place, it ensures a SessionTransaction is present to track ongoing operations. This transaction is completed when Session.commit() is called.

It is often desirable, particularly in framework integrations, to control the point at which the “begin” operation occurs. To suit this, the Session uses an “autobegin” strategy, such that the Session.begin() method may be called directly for a Session that has not already had a transaction begun:

  1. Session = sessionmaker(bind=engine)
  2. session = Session()
  3. session.begin()
  4. try:
  5.     item1 = session.get(Item, 1)
  6.     item2 = session.get(Item, 2)
  7.     item1.foo = "bar"
  8.     item2.bar = "foo"
  9.     session.commit()
  10. except:
  11.     session.rollback()
  12.     raise

The above pattern is more idiomatically invoked using a context manager:

  1. Session = sessionmaker(bind=engine)
  2. session = Session()
  3. with session.begin():
  4.     item1 = session.get(Item, 1)
  5.     item2 = session.get(Item, 2)
  6.     item1.foo = "bar"
  7.     item2.bar = "foo"

The Session.begin() method and the session’s “autobegin” process use the same sequence of steps to begin the transaction. This includes that the SessionEvents.after_transaction_create() event is invoked when it occurs; this hook is used by frameworks in order to integrate their own transactional processes with that of the ORM Session.

Enabling Two-Phase Commit

For backends which support two-phase operation (currently MySQL and PostgreSQL), the session can be instructed to use two-phase commit semantics. This will coordinate the committing of transactions across databases so that the transaction is either committed or rolled back in all databases. You can also Session.prepare() the session for interacting with transactions not managed by SQLAlchemy. To use two phase transactions set the flag twophase=True on the session:

  1. engine1 = create_engine("postgresql+psycopg2://db1")
  2. engine2 = create_engine("postgresql+psycopg2://db2")
  4. Session = sessionmaker(twophase=True)
  6. # bind User operations to engine 1, Account operations to engine 2
  7. Session.configure(binds={User: engine1, Account: engine2})
  9. session = Session()
  11. # .... work with accounts and users
  13. # commit.  session will issue a flush to all DBs, and a prepare step to all DBs,
  14. # before committing both transactions
  15. session.commit()

Setting Transaction Isolation Levels / DBAPI AUTOCOMMIT

Most DBAPIs support the concept of configurable transaction isolation levels. These are traditionally the four levels “READ UNCOMMITTED”, “READ COMMITTED”, “REPEATABLE READ” and “SERIALIZABLE”. These are usually applied to a DBAPI connection before it begins a new transaction, noting that most DBAPIs will begin this transaction implicitly when SQL statements are first emitted.

DBAPIs that support isolation levels also usually support the concept of true “autocommit”, which means that the DBAPI connection itself will be placed into a non-transactional autocommit mode. This usually means that the typical DBAPI behavior of emitting “BEGIN” to the database automatically no longer occurs, but it may also include other directives. When using this mode, the DBAPI does not use a transaction under any circumstances. SQLAlchemy methods like .begin(), .commit() and .rollback() pass silently.

SQLAlchemy’s dialects support settable isolation modes on a per-Engine or per-Connection basis, using flags at both the create_engine() level as well as at the Connection.execution_options() level.

When using the ORM Session, it acts as a facade for engines and connections, but does not expose transaction isolation directly. So in order to affect transaction isolation level, we need to act upon the Engine or Connection as appropriate.

See also

Setting Transaction Isolation Levels including DBAPI Autocommit - be sure to review how isolation levels work at the level of the SQLAlchemy Connection object as well.

Setting Isolation For A Sessionmaker / Engine Wide

To set up a Session or sessionmaker with a specific isolation level globally, the first technique is that an Engine can be constructed against a specific isolation level in all cases, which is then used as the source of connectivity for a Session and/or sessionmaker:

  1. from sqlalchemy import create_engine
  2. from sqlalchemy.orm import sessionmaker
  4. eng = create_engine(
  5.     "postgresql+psycopg2://scott:tiger@localhost/test",
  6.     isolation_level="REPEATABLE READ",
  7. )
  9. Session = sessionmaker(eng)

Another option, useful if there are to be two engines with different isolation levels at once, is to use the Engine.execution_options() method, which will produce a shallow copy of the original Engine which shares the same connection pool as the parent engine. This is often preferable when operations will be separated into “transactional” and “autocommit” operations:

  1. from sqlalchemy import create_engine
  2. from sqlalchemy.orm import sessionmaker
  4. eng = create_engine("postgresql+psycopg2://scott:tiger@localhost/test")
  6. autocommit_engine = eng.execution_options(isolation_level="AUTOCOMMIT")
  8. transactional_session = sessionmaker(eng)
  9. autocommit_session = sessionmaker(autocommit_engine)

Above, both “eng” and "autocommit_engine" share the same dialect and connection pool. However the “AUTOCOMMIT” mode will be set upon connections when they are acquired from the autocommit_engine. The two sessionmaker objects “transactional_session” and “autocommit_session" then inherit these characteristics when they work with database connections.

The “autocommit_session” continues to have transactional semantics, including that Session.commit() and Session.rollback() still consider themselves to be “committing” and “rolling back” objects, however the transaction will be silently absent. For this reason, it is typical, though not strictly required, that a Session with AUTOCOMMIT isolation be used in a read-only fashion, that is:

  1. with autocommit_session() as session:
  2.     some_objects = session.execute("<statement>")
  3.     some_other_objects = session.execute("<statement>")
  5. # closes connection

Setting Isolation for Individual Sessions

When we make a new Session, either using the constructor directly or when we call upon the callable produced by a sessionmaker, we can pass the bind argument directly, overriding the pre-existing bind. We can for example create our Session from a default sessionmaker and pass an engine set for autocommit:

  1. plain_engine = create_engine("postgresql+psycopg2://scott:tiger@localhost/test")
  3. autocommit_engine = plain_engine.execution_options(isolation_level="AUTOCOMMIT")
  5. # will normally use plain_engine
  6. Session = sessionmaker(plain_engine)
  8. # make a specific Session that will use the "autocommit" engine
  9. with Session(bind=autocommit_engine) as session:
  10.     # work with session
  11.     ...

For the case where the Session or sessionmaker is configured with multiple “binds”, we can either re-specify the binds argument fully, or if we want to only replace specific binds, we can use the Session.bind_mapper() or Session.bind_table() methods:

  1. with Session() as session:
  2.     session.bind_mapper(User, autocommit_engine)

Setting Isolation for Individual Transactions

A key caveat regarding isolation level is that the setting cannot be safely modified on a Connection where a transaction has already started. Databases cannot change the isolation level of a transaction in progress, and some DBAPIs and SQLAlchemy dialects have inconsistent behaviors in this area.

Therefore it is preferable to use a Session that is up front bound to an engine with the desired isolation level. However, the isolation level on a per-connection basis can be affected by using the Session.connection() method at the start of a transaction:

  1. from sqlalchemy.orm import Session
  3. # assume session just constructed
  4. sess = Session(bind=engine)
  6. # call connection() with options before any other operations proceed.
  7. # this will procure a new connection from the bound engine and begin a real
  8. # database transaction.
  9. sess.connection(execution_options={"isolation_level": "SERIALIZABLE"})
  11. # ... work with session in SERIALIZABLE isolation level...
  13. # commit transaction.  the connection is released
  14. # and reverted to its previous isolation level.
  15. sess.commit()
  17. # subsequent to commit() above, a new transaction may be begun if desired,
  18. # which will proceed with the previous default isolation level unless
  19. # it is set again.

Above, we first produce a Session using either the constructor or a sessionmaker. Then we explicitly set up the start of a database-level transaction by calling upon Session.connection(), which provides for execution options that will be passed to the connection before the database-level transaction is begun. The transaction proceeds with this selected isolation level. When the transaction completes, the isolation level is reset on the connection to its default before the connection is returned to the connection pool.

The Session.begin() method may also be used to begin the Session level transaction; calling upon Session.connection() subsequent to that call may be used to set up the per-connection-transaction isolation level:

  1. sess = Session(bind=engine)
  3. with sess.begin():
  4.     # call connection() with options before any other operations proceed.
  5.     # this will procure a new connection from the bound engine and begin a
  6.     # real database transaction.
  7.     sess.connection(execution_options={"isolation_level": "SERIALIZABLE"})
  9.     # ... work with session in SERIALIZABLE isolation level...
  11. # outside the block, the transaction has been committed.  the connection is
  12. # released and reverted to its previous isolation level.

Tracking Transaction State with Events

See the section Transaction Events for an overview of the available event hooks for session transaction state changes.

Joining a Session into an External Transaction (such as for test suites)

If a Connection is being used which is already in a transactional state (i.e. has a Transaction established), a Session can be made to participate within that transaction by just binding the Session to that Connection. The usual rationale for this is a test suite that allows ORM code to work freely with a Session, including the ability to call Session.commit(), where afterwards the entire database interaction is rolled back.

Changed in version 2.0: The “join into an external transaction” recipe is newly improved again in 2.0; event handlers to “reset” the nested transaction are no longer required.

The recipe works by establishing a Connection within a transaction and optionally a SAVEPOINT, then passing it to a Session as the “bind”; the Session.join_transaction_mode parameter is passed with the setting "create_savepoint", which indicates that new SAVEPOINTs should be created in order to implement BEGIN/COMMIT/ROLLBACK for the Session, which will leave the external transaction in the same state in which it was passed.

When the test tears down, the external transaction is rolled back so that any data changes throughout the test are reverted:

  1. from sqlalchemy.orm import sessionmaker
  2. from sqlalchemy import create_engine
  3. from unittest import TestCase
  5. # global application scope.  create Session class, engine
  6. Session = sessionmaker()
  8. engine = create_engine("postgresql+psycopg2://...")
  11. class SomeTest(TestCase):
  12.     def setUp(self):
  13.         # connect to the database
  14.         self.connection = engine.connect()
  16.         # begin a non-ORM transaction
  17.         self.trans = self.connection.begin()
  19.         # bind an individual Session to the connection, selecting
  20.         # "create_savepoint" join_transaction_mode
  21.         self.session = Session(
  22.             bind=self.connection, join_transaction_mode="create_savepoint"
  23.         )
  25.     def test_something(self):
  26.         # use the session in tests.
  28.         self.session.add(Foo())
  29.         self.session.commit()
  31.     def test_something_with_rollbacks(self):
  33.         self.session.add(Bar())
  34.         self.session.flush()
  35.         self.session.rollback()
  37.         self.session.add(Foo())
  38.         self.session.commit()
  40.     def tearDown(self):
  41.         self.session.close()
  43.         # rollback - everything that happened with the
  44.         # Session above (including calls to commit())
  45.         # is rolled back.
  46.         self.trans.rollback()
  48.         # return connection to the Engine
  49.         self.connection.close()

The above recipe is part of SQLAlchemy’s own CI to ensure that it remains working as expected.