activiti乐观锁与死锁

乐观锁

为什么需要采用乐观锁？

由于activiti一个周期的transaction时间可能比较长，且同一流程实例中存在任务并发执行等场景。设计者将update、insert、delete事务性的操作推迟至command结束时完成，这样尽量降低锁冲突的概率，由此产生基于mybatis上封装的session cache来管理这些中间状态的实体对象。但在充分竞争情况下锁是不可避免的，进一步利用乐观锁机制能保证执行模型的一致性。因为往往如果锁定相同数据记录说明多个相互影响的command并发执行，安全的策略就是让第一个命令成功，其他皆失败。

PS:

悲观锁，正如其名，它指的是对数据被外界（包括本系统当前的其他事务，以及来自 外部系统的事务处理）修改持保守态度，其它事务会一直阻塞，直到这个事务结束。因此，在整个数据处理过程中，将数据处于锁定 状态。悲观锁的实现，往往依靠数据库提供的锁机制（也只有数据库层提供的锁机制才能 真正保证数据访问的排他性，否则，即使在本系统中实现了加锁机制，也无法保证外部系 统不会修改数据）。

对悲观锁而言，乐观锁机制采取了更加宽松的加锁机制,不会锁住任何东西。大多是基于数据版本 （ Version ）记录机制实现，更新时，对此版本号加一。此时，将提交数据的版本数据与数据库表对应记录的当前版本信息进行比对，如果提交的数据版本号大于数据库表当前版本号，则予以更新，否则认为是过期数据予以驳回。

 

死锁

在一个command执行过程中存在开始独立的新事务