Skip to content
Aabha AI Academy

Stage 10 · L34

Give async sessions and serialization a clear owner

Optional extension · extended visuals/current Equipment runtime; not original Session 8 implementation

Optional resource implementation checked in isolated PostgreSQL/HTTP fixtures.

Native checkpoint 09

Download starter · Download solution

Use the starter for this stage's focused examples. The cumulative transfer and solution belong at the stage-end capstone. Baseline checks pass; transfer checks initially fail. Downloads contain the matching native starter and solution for this stage.

This optional extension changes the database execution model deliberately. async_resources owns an async engine and AsyncSession factory using the installed psycopg async dialect. It does not use asyncpg and does not convert the core provider preparation to async. The caller enters the resource context and awaits disposal at exit.

A factory can be shared; a mutable AsyncSession cannot be shared across concurrent units of work. export_rental creates one session for one operation. The test runs two exports concurrently through the same factory and confirms independent results. Sharing a session would mix transaction state and can fail under concurrent driver activity.

Load everything required before serialization. The query joinedloads equipment, constructs RentalDetail inside the session and returns the DTO after cleanup. A lazy relationship accessed afterward would either fail or attempt I/O from an unsupported serialization context. expire_on_commit=False can prevent scalar expiration but is not a substitute for a relationship load plan.

The guided create_customer uses async with session.begin, awaits flush for its UUID, validates CustomerOut, and lets successful exit commit. A duplicate email raises a real PostgreSQL IntegrityError and rolls back that operation; a later create still succeeds. A fresh synchronous observer verifies the committed row count. The value is an inactive customer profile, not a fabricated verified identity.

The independent transfer implements scoped async customer export and public output only. An ordinary actor can read its own UUID; another customer is masked404; an admin has the deliberate broader read scope. The DTO must serialize after session/engine cleanup without password hash, role, credential version or an ORM reference.

Owned async engine/factory; One AsyncSession per operation; Await flush + transaction completion; Load DTO fields before close; Return plain DTO after cleanup
Owned async engine/factory; One AsyncSession per operation; Await flush + transaction completion; Load DTO fields before close; Return plain DTO after cleanup

Follow the running code

Focused lesson example; see the end-of-stage capstone for the cumulative app · stage 09

async with factory() as session:
    result = await session.execute(statement_with_eager_load)
    output = RentalDetail.model_validate(result.scalar_one())
# output is plain/public and usable after owned cleanup.

Predict and observe this focused example using the concepts explained above. Its boundary is stated in the focused answer.

Guided lab

  1. Read the explanation and predict the focused example’s outcome.
  2. Implement only scoped async customer export after core completion. Explain which object concurrent tasks may share.
  3. Compare the observed outcome with the focused answer and state its boundary.

Expected: Tasks may share the engine/session factory, not one mutable AsyncSession. Each operation owns a new session, applies current actor scope, constructs CustomerOut inside it and returns a public DTO after cleanup. Another customer is masked404; the deliberate admin scope is wider. Async PostgreSQL is optional; core provider preparation remains synchronous.

  • A shared AsyncSession is unsafe for concurrent units; lazy serialization is not fixed merely by expire_on_commit=False.

Focused exercise and answer

Complete this focused exercise before reading its answer. The full native transfer is introduced only at the end of the stage.

Your transfer task: Implement only scoped async customer export after core completion. Explain which object concurrent tasks may share.

  1. Implement only scoped async customer export after core completion. Explain which object concurrent tasks may share.
Inspect the matching answer

This answer addresses the focused exercise above; the cumulative implementation is shown only after the stage prerequisites.

Tasks may share the engine/session factory, not one mutable AsyncSession. Each operation owns a new session, applies current actor scope, constructs CustomerOut inside it and returns a public DTO after cleanup. Another customer is masked404; the deliberate admin scope is wider. Async PostgreSQL is optional; core provider preparation remains synchronous.

Check your reasoning

Which object may concurrent operations share?

Show the explanation

The engine/session factory, while each operation creates and closes its own AsyncSession.

Reading progress

54 lessons remain open to guests. Marking a lesson read records reading only; it does not award assessment credit or a certificate.

Device reading marks require browser storage. Reading is always available.

Sign in or create an account to save separate account progress. Your current page is kept.