Question

我使用transaction.atomic作为django 1.6中事务的上下文管理器。我希望在一个事务中有一块代码，它有几个网络调用和一些数据库写入。我看到非常奇怪的行为。每隔一段时间（也许是20次中的1次）我注意到发生了部分回滚，没有引发任何异常并且视图执行没有任何错误。我的应用程序托管在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 有时事务不会被提交，并且没有异常提示让您知道发生了什么。有时它的一部分会被提交，而其余部分会丢失，看起来像是部分回滚。

我们认为连接是线程安全的，但是这里有一点枪炮修补魔法，确保情况并非如此：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类型一起使用，所以除非你想用完连接，否则请避免使用它。

Answer 2

不是Django专家，但我知道Postgres。我同意你的评估，这听起来像是一个非常非典型的交易行为：回滚应该是全有或全无的，应该有一个例外。既然如此，你能绝对肯定这是一种回滚型的情况吗？有许多其他可能的原因可以解释数据库中出现的不同数据超出预期，并且其中许多情况更适合您观察到的回滚事件。

你没有提供任何关于你的数据的细节，但我想象的是，你会看到类似“我将col4的值设置为'foo'，但在提交之后，旧值'bar'仍在数据库中。“那是对的吗？

如果是这样，那么其他可能的原因可能是：

应该以某种方式设置'foo'值的代码实际上是设置现有的'bar'值或NULL值。
代码设置'foo'值，但是有一个数据访问层（也称为DAL），其中'脏'标志未被设置（例如，如果对象处于断开连接状态），所以当提交完成后，DAL不会将其视为应该编写的更改。

这些只是让您入门的几个例子。还有很多其他可能的情况。有时，调试这类问题的基本理念类似于滴滴涕和鹈鹕的问题：由于数据库位于食物链的顶端，你经常可以看到那些问题 - 虽然它们似乎是数据库问题 - - 实际上是在解决方案的其他地方引起的。

祝你好运，希望有所帮助！

Answer 3

我的3美分：

例外

我们确定没有发生任何例外。但是我们呢？您的伪代码仅通过记录来“处理”异常。确保logging或pass在其他地方没有“处理”的例外情况。

部分回滚

我们希望整个交易回滚，而不仅仅是部分。由于django 1.6 嵌套原子事务创建savepoint并且回滚返回到最后一个保存点。确保没有嵌套事务。也许您有transaction middleware有效支票ATOMIC_REQUESTS和MIDDLEWARE_CLASSES。也许交易是在那些network_call函数中启动的。

再生

因为network_call代码可能会阻止。尝试用模拟调用替换它们，超时（可能不在生产中）。如果这导致100％（部分）回滚。它应该能够更容易地找到部分回滚的问题。

Answer 4

我先说几句。

没有必要在此代码中有异常并且仍然有回滚。

可能在此代码之外存在某种超时。想想你是否在第二次网络呼叫中杀死了python进程。不会记录此特殊异常。

我还建议添加

raise

在除外，它将记录并重新引发相同的异常。 Cacthing所有异常都很少。

此外，可能存在线程问题。尝试在记录器中导入threding和记录当前线程id，但有异常。您可能会发现实际上有多个线程，因此必须等待另一个线程。

通常，在事务中间进行一些外部调用并不是一个好主意。

在开始原子事务之前完成两个调用，因此它可以尽可能快。

希望这有帮助。

django 1.6.1中交易的奇怪行为

4 个答案:

例外

部分回滚

再生