update 大家会允许这样写吗？

我知道 python 的 flask 在
u.setName(myname);
u.setAge(myAge);
之后就可以直接 commit 了,
java 好像真没啥好办法, 想要性能好还要加锁就只能乐观锁了.

我感觉 v 站最多的就是 java 选手了，哈哈哈哈

@binge921 #42 对于业务代码，除了 java 没哪个语言能打的。这也侧面反映，写业务逻辑的人占据了大部分的。

和语言没关系，对于先 check 后操作的场景就是典型的竞态条件，一般要加锁。但也分场景，比如上面说的订单场景，如果每条彼此有影响，比如先 check 是否为 0 ，更新的时候再原记录-1 肯定要加锁。如果用户资料修改，更改不依赖之前数据，那加不加都无所谓，纠结什么谁覆盖了谁的更新，谁先谁后没有任何意义。网络本身都可能有波动，不一定先请求的用户就一定先收到，也不代表一定先处理完。

我写 php 的,感觉还好。
但是不需原数据做逻辑,查询就多余了。

看到有说全部更新?
应该不会吧,orm 会跟原数据对比,只更新改变的字段。

字符串并发有什么影响??? 又不是金额之类的数字。
就算是金额,你也要查询出来做校验啊!
你这代码场景,我看不出有并发问题。

这个得看 orm 的实现还有配置？
有的 orm 更新可以提供 TX 的

@Vegetable
我擦,刚注意到你这个描述了。
这已经是 bug 了!
这么写,只能说脑*了。

user 场景来说，一般没什么问题，基本不会有什么并发。但这种全字段更新的，乐观锁控制下会减少点并发的问题。JPA 有自动乐观锁，不一定在这里体现。

这里并发会有数据安全的问题。
如果不是业务场景迫不得已要先查询再根据查询的数据进行更新，不要这么写，直接 update 就好。
有些业务情况下，有时必须要先查询再进行更新，这种情况建议加锁（乐观锁也好、其他方式加悲观锁也好）。

这个不能加 where 条件么？不满足条件不更新，就不会更新到已经被人更新过的数据了？

一楼已经给出答案

我不懂 java
java 中没有原子操作吗

并发问题很大，必须上锁。

先读后写的情况下不都是事务了，没有并发问题。难带这种代码还没事务的吗。

哪有那么多并发问题..一般不会更新别人的数据吧，更新自己的数据客户端卡下，偶尔出问题运维下好了

1. 加锁
2. 用 repeatable_read 事务

但是不管哪种方式都或多或少影响性能

python 的 sqlalchemy 就超级无语，select 的时候就自动开启事务，还关闭不了

根据你业务量决定，在一个就是关于金融积分等要避免，其他无所谓吧

取决于你前置请求是否有类似防抖的操作，如果有校验登陆状态和防抖并发的情况这代码本身并没有什么问题。
登陆状态都合法，也都是用户自己操作的，非敏感数据（金额扣减/状态变更等等）并不需要加太多限制，不然除了降低性能提高复杂度之外没有任何正向收益。

绝对打回