关于事务与并发

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

   咱们公司的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系统里面的第一个事务未执行完毕就执行了第二个事务。由这个问题咱们能够引伸出不少的事务并发问题，比方说在设计一个系统的时候，当涉及到某些表里面的状态字段时，咱们更多须要的是一个流程化的设计，而不是状态是随便在哪一个环节就能够改变的，要是真有那种需求的话，就是使用数据库的锁了，不过通常是不会这么设计的，若是要我选择的话，我以为流程化会更加好一点。