How should you scope SQLAlchemy sessions across requests, threads, and async tasks?

Defines one explicit SQLAlchemy session and transaction owner for each request, job, thread, or async task.

1Say itAnswer out loud first

2CompareCompare with Core answer

3RefineRefine with Stronger and Advanced

TL;DR

A SQLAlchemy Session is mutable state for one database transaction, so I do not share it across concurrent threads. The same rule applies to AsyncSession: one instance should not be used by several concurrent tasks. I create a session from a shared factory for one request, command, or job, pass it through that unit of work, then commit or roll back and close it reliably with a context manager.

Full answer below

Practice focus

Defines one explicit SQLAlchemy session and transaction owner for each request, job, thread, or async task.

Answer first

Answer path

Core answer first, then checkpoints toward a stronger answer.

Start
Core answer
Start here. This is the direct spoken answer to practice first.
Overview
Defines one explicit SQLAlchemy session and transaction owner for each request, job, thread, or async task.
A SQLAlchemy Session is mutable state for one database transaction, so I do not share it across concurrent threads. The same rule applies to AsyncSession: one instance should not be used by several concurrent tasks. I create a session from a shared factory for one request, command, or job, pass it through that unit of work, then commit or roll back and close it reliably with a context manager.
Checkpoint
Stronger answer
Optional upgrade with examples, trade-offs, and sharper phrasing.
Session-per-request is a lifetime guideline, not a command to commit at every repository call. The application boundary decides whether several writes belong in one transaction. If a request starts concurrent database branches, each branch needs its own AsyncSession and therefore its own transaction; that changes consistency and capacity, so sequential queries are often the honest design. Background work must open its own session instead of retaining a request-scoped one.

Review signals

Use these to catch weak phrasing, shallow reasoning, and risky claims.

Common mistakesCandidateCommon mistakesMistakes that weaken the answer or signal shallow understanding.Open details

Details

Using a global Session
Sharing one AsyncSession inside gather
Passing a request Session to background work

How should you scope SQLAlchemy sessions across requests, threads, and async tasks?

Practice focus

Answer path

Overview

Review signals

Follow-up prompts

Continue the section

Tech stacks

Skill areas

Suggest an improvement

Found this answer useful?