数据库的事务、锁、应用层的 service 接口问题

一般情况下是 读取表 写个 select 更新表写个 update, 其他都不用管.

两个接口各干各的会有什么问题吗

如果是两个接口 为啥要“保证数据正确”呢

一般只有在单个事务场景才会需要保证强一致性

这和串行不串行没啥关系，因为你没法知道调用方”读“多久，除非它主动告诉你自己”读“使用完了

如果要锁的话，锁的生命周期就是得由调用方来控制了

没懂啥意思 update 的 service 方法加事务就行吧防止读未提交或出现回滚 查询不用管

没理解，读、写接口本来就互不影响，可以详细说说 (:

```需求是保证数据正确```
你设置 db isolation level 不要是 read uncommitted 就可以了。
读取和写为啥要互斥呢=。 除非是写和写之间。

最简单的做法就是加一个分布式锁保证两个接口互斥， 但是如果你数据库有主从的话，也没办法保证拿到的一定是最新的数据。

应用层的 Service 应该是要退出讨论的，你描述就是并发环境下的数据库修改。不同 db 的限制不同，例如 mysql 就是 mvcc ，不同的事务等级在遇到并发问题的处理方案不同。

这个看起来有些奇怪，不过按照你这个需求，在应用层上倒是有一些思路：

写的接口传入读的数据，写入前进行校验，如果不一致抛出信息。

你的需求只需要保证读取出来的不是未提交的写入就可以了，把数据库的事务等级调整一下就好了，就是 6l 的建议；
或者你想在后端实现，其实也简单，实现一个简单的 cas 就行，比如给表加个 version 字段

照你现有的描述的话压根不需要做任何处理。
怀疑你描述有问题，猜测是为了读取内容后立即修改，如果是这样就是最基本的写并发问题。

感觉具体得看什么属性的数据。
1.如果是共享数据，如果不锁住读取的表内容，就会有并发导致的数据不正确的风险。可以在数据库中加一个乐观锁/悲观锁。
2.不是共享数据，串行化就 ok

@xiaogu2014 如果不互斥的话，读到的数据 可能不是最新的数据吧

@heiya 是共享的数据