多线程场景下使用SQLAlchemy ORM操作内存SQLite报错问题

问题根因 #

报错本质由以下两点共同导致：

• 配置的StaticPool为单连接池，所有线程共享同一个数据库连接。SQLite本身不支持在同一个连接上同时开启多个事务，多线程并发提交时就会触发cannot start a transaction within a transaction错误
• 加echo=True可正常运行属于巧合，本质是日志打印的IO操作拖慢了线程执行速度，刚好让各线程的事务提交时机错开，不是可靠的解决方案
• 后续的参数绑定错误也由并发场景下多个线程同时修改同一个连接的上下文参数导致

可行修复方案 #

方案1：加锁控制写操作（最小改动兼容现有逻辑） #

在写提交入口加线程锁，保证同一时间只有一个线程执行提交逻辑即可，修改成本极低：

import threading
write_lock = threading.Lock()

def insert_items():
    session = Session()
    for i in range(1000):
        session.add(Item(data=i))
    # 提交前加锁
    with write_lock:
        session.commit()
    Session.remove()

方案2：队列串行化写（稳定性最高） #

SQLite本身仅支持单写并发，更合理的架构是用队列把所有写请求统一放到单线程中执行，彻底避免并发冲突，同时可以通过批量提交优化性能：

from queue import Queue
import threading
from sqlalchemy import text

write_queue = Queue()
BATCH_COMMIT_SIZE = 5000

def write_worker():
    session = Session()
    pending_count = 0
    while True:
        items = write_queue.get()
        if items is None:
            # 收到退出信号提交剩余数据
            if pending_count > 0:
                session.commit()
            break
        session.add_all(items)
        pending_count += len(items)
        # 攒够批量阈值或者队列为空时提交
        if pending_count >= BATCH_COMMIT_SIZE or write_queue.qsize() == 0:
            session.commit()
            pending_count = 0
        write_queue.task_done()

# 启动常驻写线程
worker_thread = threading.Thread(target=write_worker, daemon=True)
worker_thread.start()

# 业务线程仅需往队列投递数据即可
def insert_items():
    items = [Item(data=i) for i in range(1000)]
    write_queue.put(items)

方案3：改用磁盘SQLite+WAL模式（适用于不需要纯内存存储的场景） #

磁盘SQLite可以开启多连接池，每个线程拿独立连接，配合WAL模式可以实现读写并发，引擎配置参考：

in_memory_engine = create_engine(
    'sqlite:///app_data.db',
    connect_args={'check_same_thread': False},
    pool_size=10,
    max_overflow=20,
    execution_options={"isolation_level": "READ COMMITTED"}
)
# 开启WAL模式
with in_memory_engine.connect() as conn:
    conn.execute(text("PRAGMA journal_mode=WAL;"))
    conn.commit()

补充说明 #

scoped_session仅能保证同一个线程拿到同一个session实例，无法解决多线程争抢同一数据库连接的问题，因此之前测试用不用scoped_session表现一致。如果业务有高并发写需求，建议直接换用MySQL、PostgreSQL等C/S架构的关系型数据库，更匹配场景需求。

内容的提问来源于stack exchange，提问作者Dmitry