django - django 1.6.1 中事务的奇怪行为

Question

我正在使用 transaction.atomic 作为 django 1.6 中事务的上下文管理器。我想在一个事务中有一段代码，它有几个网络调用和一些数据库写入。我看到非常奇怪的行为。每隔一段时间(可能是 20 次中的 1 次)我注意到发生了部分回滚，没有引发任何异常，并且 View 执行没有任何错误。我的应用程序托管在 heroku 上，我们使用 heroku postgres v9.2.8。伪代码:

from django.db import transaction

def some_view(request):

    try:
        with transation.atomic():
            network_call_1()
            db_write_1.save(update_fields=['col4',])
            db_write_2.save(update_fields=['col3',])
            db_write_3.save(update_fields=['col1',])
            network_call_2()
            db_write_4.save(update_fields=['col6',])
            db_write_5.bulk_create([object1, object2])
            db_write_6.bulk_create([object1, object2])
    except Exception, e:
        logger.error(e)

    return HttpResponse()

我注意到的行为是，在没有引发任何异常的情况下，db write 1-3 已经回滚，其余的已经完成，或者 db write 1 已经回滚，其余的已经完成，依此类推。我不明白为什么会这样。第一，如果有回滚，不应该是事务的完全回滚吗？如果有回滚，不应该也引发异常以便我知道回滚已经发生了吗？每次发生这种情况时，都不会引发异常，代码会继续执行并返回成功的 HttpResponse。

相关设置:

DATABASES = {
    'default': {
        'ENGINE': 'django.db.backends.postgresql_psycopg2',
        'NAME': 'mydb',
        'USER': 'root',
        'PASSWORD': 'root',
        'HOST': 'localhost',
        'PORT': '5432',
    },
}
CONN_MAX_AGE = None

这个错误让我困惑了好几天。任何线索都会有很大帮助!

Answer 1

经过几个小时的调试，我们找到了罪魁祸首。

当我们在 gunicorn 上启动我们的应用程序时，它会生成 worker。到达同一个工作人员的每个请求都使用相同的 django DatabaseWrapper 实例(在我们的例子中是 postgres)，也称为连接。如果在一个请求的事务处理过程中，工作人员要接收另一个请求，则此请求会重置连接状态，导致事务以意外方式运行，如以下错误中所述:https://code.djangoproject.com/ticket/21239有时事务没有被提交并且没有异常被引发让你知道发生了。有时它的一部分确实被提交而其余部分丢失了，这看起来像是部分回滚。

我们认为连接是线程安全的，但这里的 gunicorn 补丁魔法确保情况并非如此:https://github.com/benoitc/gunicorn/blob/18.0/gunicorn/management/commands/run_gunicorn.py#L16

如果可能的话，仍然对如何回避这个问题的建议持开放态度。

编辑:不要使用 run_gunicorn 管理命令来启动 Django。它做了一些时髦的修补，导致数据库连接不是线程安全的。对我们有用的解决方案是只使用“gunicorn myapp.wsgi:application -c gunicorn.conf”。 Django 持久数据库连接不适用于 gevent worker 类型，因此除非您想用完连接，否则请避免使用它。