django 1.6.1中交易的奇怪行为

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类型一起使用,所以除非你想用完连接,否则请避免使用它.