2回答

Qiujuer

2020-10-26

已采纳

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

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

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

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

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

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

0

3

Qiujuer

回复

慕用0425495

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

2020-10-26

共3条回复

慕用0425495

提问者

2020-10-25

另外的问题是: 在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, 

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

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

0

0