无效交易在请求中持续存在

  • Z时代
  • 2024-01-10
  • 分类：问答

摘要

我们生产中的一个线程在InvalidRequestError: This session is in ‘prepared’ state; no further SQL can be emitted within this transaction.整个生命周期中都遇到错误，并且现在在每次请求中都产生错误，并为其提供查询。现在已经有好几天了！这怎么可能？我们如何防止这种情况继续下去？

背景

我们在uWSGI（4个进程，2个线程）上使用了Flask应用程序，并且Flask-SQLAlchemy为我们提供了到SQL Server的数据库连接。

当我们的生产中的一个线程在Flask-SQLAlchemy方法内部拆除请求时，问题似乎开始了：

@teardown
def shutdown_session(response_or_exc):
    if app.config['SQLALCHEMY_COMMIT_ON_TEARDOWN']:
        if response_or_exc is None:
            self.session.commit()
    self.session.remove()
    return response_or_exc

…并self.session.commit()在交易无效时设法以某种方式致电。这导致sqlalchemy.exc.InvalidRequestError: Can't reconnect until invalid transaction is rolled back将输出输出到stdout，这违反了我们的日志记录配置，这是有道理的，因为它发生在应用程序上下文崩溃期间，这种情况永远不会引发异常。我不确定交易如何在不进行response_or_exec设置的情况下无效，但这实际上是AFAIK较小的问题。

更大的问题是，这是“准备好的状态”错误开始的那一刻，并且此后一直没有停止过。每当该线程处理一个命中数据库的请求时，它的响应时间为500s。每个其他线程似乎都不错：据我所知，即使是处于同一进程中的线程也可以正常运行。

Wild guess

SQLAlchemy邮件列表中有一个有关“’prepared’state”错误的条目，该错误表示如果会话开始提交但尚未完成，并且其他尝试使用它，则会发生该错误。我的猜测是，该线程中的会话从未达到self.session.remove()目标，现在它永远也不会执行。

我仍然觉得这并不能解释此会话如何在请求中持续存在。我们尚未修改Flask-SQLAlchemy对请求范围的会话的使用，因此该会话应返回到SQLAlchemy的池中，并在请求结束时回滚，即使是发生错误的会话也可以回滚（尽管坦白地说，可能不是第一个， （因为在应用上下文中发生的崩溃）。为什么不进行回滚？如果我们每次都在stdout上（在uwsgi的日志中）看到“无效事务”错误，我就可以理解，但事实并非如此：我第一次只看到一次。但是每次出现500秒钟时，我都会在应用日志中看到“’prepared’state”错误。

配置细节

我们已经在中关闭expire_on_commit了session_options，然后又打开了SQLALCHEMY_COMMIT_ON_TEARDOWN。我们仅从数据库中读取，尚未写入。我们还在所有查询中使用Dogpile-Cache（使用memcached锁，因为我们有多个进程，实际上是2个负载平衡的服务器）。对于我们的主要查询，缓存每分钟都会过期。

解决步骤

重新启动服务器似乎已解决了问题，这并不完全令人惊讶。就是说，我希望再次看到它，直到我们弄清楚如何停止它为止。benselme（下）建议编写自己的拆卸回调，并在提交周围进行异常处理，但是我觉得更大的问题是线程在整个余生中都被弄乱了。一两个请求后这一切都没有消失的事实让我很紧张！

回答：

TL; DR：请务必使用拆解包装配方，确保拆解功能成功！

我还使用Flask开始了一项新工作，在我准备好拆包食谱之前，这个问题再次弹出。因此，我重新审视了这个问题，并最终弄清了发生了什么。

正如我认为的那样，每当新请求下线时，Flask都会将新的请求上下文推送到请求上下文堆栈中。这用于支持请求本地全局变量，例如会话。

Flask还具有与请求上下文分离的“应用程序”上下文概念。它旨在支持未发生HTTP的测试和CLI访问等功能。我知道这一点，而且我也知道那是Flask-SQLA放置其数据库会话的地方。

在正常操作期间，请求和应用程序上下文都在请求开始时被推送，并在结束时弹出。

但是，事实证明，当推送请求上下文时，请求上下文会检查是否存在现有的应用程序上下文，如果存在，则不会推送新的应用程序上下文！

因此，如果由于拆解功能的提高而在请求结束时未弹出应用程序上下文，那么它不仅会永远存在，甚至不会在其之上放置新的应用程序上下文。

这也解释了我在集成测试中没有理解的一些魔术。你可以插入一些测试数据，然后运行一些请求，即使你不提交，这些请求也将能够访问该数据。因为请求具有新的请求上下文，但由于重用了测试应用程序上下文，所以这是可能的，因此它重用了现有的数据库连接。因此，这确实是一个功能，而不是错误。

就是说，这确实意味着你必须绝对确保你的拆卸功能能够成功使用下面的拆卸功能包装器之类的东西。即使没有该功能，这也是一个好主意，以避免内存和数据库连接泄漏，但是鉴于这些发现，这一点尤其重要。因此，我将向Flask的文档提交PR。

我们最后放置的一件事是下面的代码（在我们的应用程序工厂中），该代码包装了所有拆卸函数以确保它记录了异常且不会进一步引发。这样可以确保始终成功弹出应用上下文。显然，这必须在你确定所有拆卸功能都已注册之后进行。

# Flask specifies that teardown functions should not raise.
# However, they might not have their own error handling,
# so we wrap them here to log any errors and prevent errors from
# propagating.
def wrap_teardown_func(teardown_func):
    @wraps(teardown_func)
    def log_teardown_error(*args, **kwargs):
        try:
            teardown_func(*args, **kwargs)
        except Exception as exc:
            app.logger.exception(exc)
    return log_teardown_error
if app.teardown_request_funcs:
    for bp, func_list in app.teardown_request_funcs.items():
        for i, func in enumerate(func_list):
            app.teardown_request_funcs[bp][i] = wrap_teardown_func(func)
if app.teardown_appcontext_funcs:
    for i, func in enumerate(app.teardown_appcontext_funcs):
        app.teardown_appcontext_funcs[i] = wrap_teardown_func(func)

以上是 无效交易在请求中持续存在 的全部内容， 来源链接： utcz.com/qa/425928.html

回到顶部