关于事务与并发

今天看到一个技术群里面聊到事务与并发的关系，发现好多开发者的理解不一样，想把自己再工作中遇到的例子在这里呈现出来，以告诉大家自己所理解的事务与并发，先简单说下流程吧！

我们公司的A,B系统通信使用的是ActiveMQ，主要是订单状态的通信，之前遇到的一个问题是A系统通过一个事务修改了订单的状态要通过ActiveMQ通知B系统，B系统收到通知并处理后会再通过ActiveMQ告知A系统通知完毕，再这个过程中订单在A系统里面有一个字段来标示订单状态，简要的步骤就是：

• A系统处理一个事务后修改订单状态
• 通过ActiveMQ通知B系统，B系统收到通知后再通过ActiveMQ告知A系统
• A系统再启动一个事务修改订单状态
• 假设订单状态正常由第一步骤到第三步骤的状态变化为pending---finish

我们遇到的问题是什么呢？经过上述步骤之后发现A系统里面的有些订单状态还是处于pending，而根据日志可以看到A系统是收到了B系统里面的消息的，并且可以确认A系统里面的两个事务都是有执行的。

也就是说，在A系统里面，有些订单的第二个事务是执行在第一个事务之后的。

后来查看了一下代码，发现我们的代码实现实际上是这样的，上面过程的第二步骤发生在第一步骤的事务未执行完就通知了B系统，这就可以解释上面的现象了，由于订单和网络传输的差异造成A系统事务执行顺序的差异。

解决方法：将代码里面通知B系统的模块移到A系统里面的第一个事务执行完毕之后。

这里面就有事务跟并发的关系了，在A系统里面按照正常流程会启动两个顺序不同的事务来修改订单的状态，而由于代码编写的问题造成A系统里面的第一个事务未执行完毕就执行了第二个事务。由这个问题我们可以引申出很多的事务并发问题，比方说在设计一个系统的时候，当涉及到某些表里面的状态字段时，我们更多需要的是一个流程化的设计，而不是状态是随便在哪个环节就可以改变的，要是真有那种需求的话，就是使用数据库的锁了，不过一般是不会这么设计的，如果要我选择的话，我觉得流程化会更加好一点。