Race condition when using @transaction() decorator

[steinitzu]

When using @transaction() as a decorator, all calls to the function use the same connection and therefor concurrent calls share the transaction scope, causing all kinds of race-condition mischief.

This is not an issue when using the transaction as a context manager as then the connection is allotted during function call rather than at import time.

Example, calling update_person multiple times concurrently here causes error:

asyncpg.exceptions._base.InterfaceError: cannot commit; the transaction is already committed

import asyncio
import contextvars

from databases import Database

db = Database("postgresql://dev:dev@localhost:6808/dev")


async def init():
    create_table = """
    CREATE TABLE person
    (
    id INTEGER PRIMARY KEY,
    name VARCHAR(100)
    );
    """
    await db.connect()
    await db.execute(create_table)
    await db.execute("INSERT INTO person (id, name) VALUES (1, 'bob')")


@db.transaction()
async def update_person():
    await db.fetch_one("SELECT * FROM person WHERE id = 1")
    await db.execute("UPDATE person SET name='joe' WHERE id = 1")


async def update_concurrently():
    await init()
    """
    Call `update_person` 6 times concurrently,
    simulating e.g. concurrent requests in a web app
    """
    tasks = []
    for i in range(6):
        ctx = contextvars.Context()
        tasks.append(ctx.run(asyncio.create_task, update_person()))
    await asyncio.gather(*tasks)


loop = asyncio.get_event_loop()

loop.run_until_complete(update_concurrently())

[zevisert]

This bug with @db.transaction should be fixed in #546, and be safe for concurrent usage again. When that's released, please let me know if this still affects you.

I have tested your MVE on the branch and I'm not seeing that error anymore. Thank you for a functional and complete example! And props for noticing that is was due to contextvars! 👏