事务隔离级别

Question

如图, 应该怎样操作才能设定ITransaction的事务隔离级别最低为Repeatable read来避免不可重复读的问题 ? 考虑多个事务并发的情况下 .

Answer 1

Qiujuer 2020-10-26 10:42:31

首先你的考虑算是比较深入的，但是对于客户端来说其实也是没必要的。

我们的项目中使用的是DBFlow，这个框架本质就是线程安全的，所以你下面追加的增加锁的操作，其实是没有必要的，完全不必担心对于数据库的操作会导致数据混乱。

在DbFlow的操作中所有的事务最终都会调度到内部框架的线程上来，而在其内部方法上对于数据的操作本身是线性的，这是保障数据库底层的前提。

当然存在业务混乱的情况，比如有A、B两个操作都要修改数据库，但是我们期望A先修改后B再进行修改，而不是A去覆盖B的值，这种情况是需要业务自己控制事务的提交，是需要业务自己去解决线程冲突问题；而这些也是在业务层面处理就好了，反而在事务处理的内部是没有必要去加锁的，无论是乐观还是悲观。除非你要存储的数据比如list是可变的，这对list加锁是有必要的。

而想要锁通过这里加锁来保障数据库的安全其实是没有必要的。

当然上述来说都是业务相对比较复杂，并且数据量较多的情况才需要进行对应的优化，常规情况下在客户端都无需考虑。

• 提问者 慕用0425495 #1

  非常感谢！

• 提问者 慕用0425495 #2

  后来仔细查阅一下MySql 的事务原理, 发现确实多个事务并发条件下, 事务隔离内部已经定义了乐观锁（除非代码层面显式限定悲观锁）行锁, 表锁, GAP锁等等来保证脏读，不可重复读，幻读问题. 最终还是要靠数据库内部的锁来落实，外部靠业务代码很难保证避免上述问题。如果需要业务代码上锁，确实情况大部分会在多个事务提交时间难以控制上, 但是一旦提交, 在数据库内部的insert, update冲突或者select数据一致性问题是数据库内部解决的。

• Qiujuer 回复 提问者 慕用0425495 #3

  是的，外部来说只能控制顺序，而对于数据文件的最终更改其实都无需担心的，数据库本身有针对这些的优化，DbFLow框架也有，所以无需担心。

Answer 2

提问者 慕用0425495 2020-10-25 16:26:47

另外的问题是: 在ITransaction.execute(datawrapper) 方法内部对数据表加乐观锁是否可行 ? 

若是加悲观锁, 那么是否是

new ITransaction() {
   @Override
   public void execute(DatabaseWrapper databaseWrapper) {

    synchronized{ tClass }{

         ModelAdapter<Model> adapter = FlowManager.getModelAdapter(tClass);
         adapter.saveAll(Arrays.asList(models));

        instance.notifySave(tClass, models); 

    }

}

这样保证在同一个数据表上的事务都是串行的 ? 

但如此显然效率非常低下, 那么有没有

先设定Transaction isolation level, 

并且在代码中能够体现多事务并发情况下, 表使用了表级锁或行级锁的办法 ? 

本人对这块不太熟悉, 谢谢回答了 .