事务作为并发访问数据库一种有效工具，如果使用不当，也会引起问题。mysql是公司内使用的主流数据库，默认事务隔离级别是可重复读。
本文尝试结合django解释应用开发中并发访问数据库可能会遇到的可重复读引起的问题，希望能帮助大家在开发过程中有效避免类似问题，如果老版本应用中出现这类问题也可以快速定位。
由于django1.3（由于历史原因，目前蓝鲸体系内大多数稳定运营的工具系统用的是django1.3）中该问题最为严重，本文先对django1.3环境中的一个应用案例进行分析，说明问题产生的具体原因，然后说明如何有效避免类似问题，最后介绍较新版本django中事务实现原理（django1.6开始已经很好避免本文案例中的大多数情况），并提供一个django1.8中由于对事务使用不当造成的异常案例。
先看下如下这段代码在django1.3中会有什么问题：
通过链接http://127.0.0.1:8000/simple_test/请求得到的结果是500错误, 如果开启了debug，则可以看到如下错误信息：
这个执行结果有点让人吃惊，本应该返回False才对。
为了快速说明该问题产生的原因，这里将请求simple_test过程中simple_test和后台任务set_data_in_backend所执行的sql语句分别打印出来：
simple_test响应请求过程执行的sql：
后台任务set_data_in_backend执行过程中执行的sql语句：
结合simple_test响应过程执行的sql语句来看，就比较好理解上面的500错误duplicate entry了。响应开始的时候, 开发框架进行了一次用户登录认证，django设置了autocommit为False,这会直接开启一个事务，
这时key=6e3247f8-31c5-46d7-a3e9-1c855077ea56的记录还不存在，由于mysql默认的事务隔离级别是可重复读,因此在simple_test整个事务期间，都找不到key=6e3247f8-31c5-46d7-a3e9-1c855077ea56的记录，所以simple_test执行到get_or_create会尝试插入一条记录key=6e3247f8-31c5-46d7-a3e9-1c855077ea56，但是在此之前后台任务已经向数据库中插入了这个key，simple_test执行get_or_create的时候mysql就给直接报一致性错误。
弄明白了这个异常发生的原理之后，我们可能会吓出一身冷汗，如果写个while循环一直去查询数据库中任务的状态到完成状态，岂不是死循环了。在django1.3中的确是这样，因为这个问题django1.3中的cache框架就被提交了Bug，django1.3遵循的是PEP 249Python数据库API 规范v2.0, 需要将autocommit初试设置为关闭状态。到了Django1.6之后已经覆盖了这个默认规范并且将autocommit设置为 on. 因此新版本的django出现上述问题的概率会大大降低。
我们可能会有些相对稳定运营的django1.3在生产环境，如果真的出现了类似的问题，可以尝试从几个方面修复：
（1）调整中间件，对登录认证完成之后进行一次commit操作。部分因为中间件过早开启事务的情形有用，比如本文的案例。
（2）发生类似错误时，显式进行一次commit操作。这种解决方式比较直观，但是如果错误本身就发生在事务中则会过早提交事务。
（3）如果只是需要把记录拿出来更新，可以考虑直接写sql更新记录。
为了说明django1.8中事务实现机制如何与django1.3不一样，将本文开始时使用案例放在django1.8中执行，调用的sql如下：
从django1.8中执行的sql可以看出，Django1.8的默认行为是运行在自动提交模式下。任何一个查询都立即被提交到数据库中，除非显示激活一个事务。最后，django1.8只是将这种可重复读引起问题的概率降低了很多，如果我们在事务中处理不当，也会引起类似问题，django本文最开始的例子进行稍微调整，在django1.8中运行一样会报错。