采纳答案成功!
向帮助你的同学说点啥吧!感谢那些助人为乐的人
如图, 应该怎样操作才能设定ITransaction的事务隔离级别最低为Repeatable read来避免不可重复读的问题 ? 考虑多个事务并发的情况下 .
首先你的考虑算是比较深入的,但是对于客户端来说其实也是没必要的。
我们的项目中使用的是DBFlow,这个框架本质就是线程安全的,所以你下面追加的增加锁的操作,其实是没有必要的,完全不必担心对于数据库的操作会导致数据混乱。
在DbFlow的操作中所有的事务最终都会调度到内部框架的线程上来,而在其内部方法上对于数据的操作本身是线性的,这是保障数据库底层的前提。
当然存在业务混乱的情况,比如有A、B两个操作都要修改数据库,但是我们期望A先修改后B再进行修改,而不是A去覆盖B的值,这种情况是需要业务自己控制事务的提交,是需要业务自己去解决线程冲突问题;而这些也是在业务层面处理就好了,反而在事务处理的内部是没有必要去加锁的,无论是乐观还是悲观。除非你要存储的数据比如list是可变的,这对list加锁是有必要的。
而想要锁通过这里加锁来保障数据库的安全其实是没有必要的。
当然上述来说都是业务相对比较复杂,并且数据量较多的情况才需要进行对应的优化,常规情况下在客户端都无需考虑。
非常感谢!
后来仔细查阅一下MySql 的事务原理, 发现确实多个事务并发条件下, 事务隔离内部已经定义了乐观锁(除非代码层面显式限定悲观锁)行锁, 表锁, GAP锁等等来保证脏读,不可重复读,幻读问题. 最终还是要靠数据库内部的锁来落实,外部靠业务代码很难保证避免上述问题。如果需要业务代码上锁,确实情况大部分会在多个事务提交时间难以控制上, 但是一旦提交, 在数据库内部的insert, update冲突或者select数据一致性问题是数据库内部解决的。
是的,外部来说只能控制顺序,而对于数据文件的最终更改其实都无需担心的,数据库本身有针对这些的优化,DbFLow框架也有,所以无需担心。
另外的问题是: 在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,
并且在代码中能够体现多事务并发情况下, 表使用了表级锁或行级锁的办法 ?
本人对这块不太熟悉, 谢谢回答了 .
登录后可查看更多问答,登录/注册
客户端+服务端+MVP架构+封装思想+主流框架
1.6k 3
3.0k 6
1.5k 18
1.3k 16
1.4k 16