Sqlalchemy：使用decorator为多个函数提供线程安全会话

Question

我正在研究像这里类似的东西（sqlalchemy的多线程应用程序），所以我明白，我应该为每个db-query创建一个新的会话。

我想知道，如果为每个方法使用装饰器，需要DB访问才有意义，或者是否有使用此方法的陷阱。 装饰器是按照这里的最后一个例子构造的 。

def dbconnect(func):
    def inner(*args, **kwargs):
        session = Session()  # with all the requirements
        try:
            func(*args, session=session, **kwargs)
            session.commit()
        except:
            session.rollback()
            raise
        finally:
            session.close()
    return inner

@dbconnect
def some_function(some, arguments, session)
    session.query(...) # no commit, close, rollback required

some_function("many", "different_arguments") 
#session is not required, since provided by decorator

这样可以很容易地为任何函数提供线程安全的DB访问，而不需要实现整个try-except-finally-stuff冗余，但我不确定，如果这种方法是故障安全和pythonic，或者是否存在另一种最佳实践。

Answer 1

我认为使用scoped_session是scoped_session ，也许是这样的：

session_factory = sessionmaker(bind=some_engine)
Session = scoped_session(session_factory)

def dbconnect(func):
    def inner(*args, **kwargs):
        session = Session()  # (this is now a scoped session)
        try:
            func(*args, **kwargs) # No need to pass session explicitly
            session.commit()
        except:
            session.rollback()
            raise
        finally:
            Session.remove()  # NOTE: *remove* rather than *close* here
    return inner

@dbconnect
def some_function(some, arguments):
    session = Session()
    # 'session' is  now a handle to the *same* session as in the decorator
    session.query(...) # no commit, close, rollback required

some_function("many", "different_arguments") 
#session is not required, since provided by decorator

（警告：未经测试）

Answer 2

添加参数的装饰器很有趣，但可能很棘手。 现在定义的参数列表与调用者实际使用的内容不一致。 如果你明确地将session=something传递给它，它将引发异常（尽管你可以在装饰器中检查它）

您还需要添加至少一个functools.wraps （已授予，这是简短的示例代码）。

事务是上下文管理器的一个很好的用例。 请参阅多线程sqlalchemy webapp中推荐的scoped_session使用模式是什么？ 对此有所了解。