今天接到一个技术任务,要改造一下当前的数据库,实现一下乐观锁。项目用了 mybatis-plus ,所以我准备用数据库表添加 version 字段的方式进行操作,配合框架的插件配置,可以实现 updateById(),update(entity,wrapper)这两个方法的更新乐观锁,但是项目中还有其他的更新方式是自定义的 mapper ,对于这部分的内容,应该用什么方式比较好呢?目前我想到的就是在 sql 解析的时候看看能不能有切入点。 望各位大佬不吝赐教!
1
ferock 2022-06-28 23:48:58 +08:00 via iPhone
自定义 mapper 那就手写 sql 呀
|
2
dqzcwxb 2022-06-29 00:40:01 +08:00
就别折腾数据库的锁了,跨库直接 gg
上分布式锁不好吗,简单又好用 |
3
jin2ml OP @ferock 你说的没错,手写肯定可以满足需求,但是我还是想知道是否可以通过拦截器这类的方式进行统一修改,这样工作量也会小些。
|
4
jin2ml OP @dqzcwxb 目前我们都是单库,而且我们项目实现的 Redis 锁我看了源码了也不支持分布式锁,只能单机适用,解锁的操作都不是原子性的,锁的客户端 id 还是 UUID 实现的无法做到分布式唯一。。。今天我去公司看看能不能睡服领导^_^!
|
6
chengyiqun 2022-06-29 09:15:24 +08:00
@jin2ml #4 睡服.... 我大写的服
|
7
themostlazyman 2022-06-29 09:18:41 +08:00
|
8
themostlazyman 2022-06-29 09:22:36 +08:00
@themostlazyman 没读清题,建议把手写 sql ,改成 updateById(),update(entity,wrapper);
|
9
haoooooo 2022-06-29 09:27:28 +08:00
睡服 屌爆!
|
10
nothingistrue 2022-06-29 09:37:54 +08:00
乐观锁原本就是个软规范,你用硬规范是很难搞定的。如果非要搞,不要在 updateById(),update(entity,wrapper) 这些方法上搞,而是从 实体 Entity 上搞,乐观锁的主体是实体,不是 CRUD 方法。
以上仅限于新项目可搞,老项目就算了,强搞建议直接提桶跑路。因为乐观锁的主体是实体,这意味仅借助而非强依赖于实体的操作——比如自定义 mapper ,是搞不了乐观锁的。所以要搞必须额外加规范:一切以实体为主。这样老项目根本搞不了,改造难度太大了。 此外,乐观锁属于程序的范畴,不是 SQL 的范畴,你发错节点了。 |
11
cheng6563 2022-06-29 09:51:22 +08:00
老系统一堆意义不明的 UPDATE 就别乐观锁了
|
12
wqhui 2022-06-29 10:35:47 +08:00
https://baomidou.com/pages/2976a3/#mybatisplusinterceptor ,mybatis-plus 的乐观锁拦截器是通过这个去做的,可以自己写一个拦截器放进去,或者实现 org.apache.ibatis.plugin.Interceptor
|
13
zmal 2022-06-29 10:42:26 +08:00 1
代码层面可能无法强制规范,是否可以建 version + id 的索引,强制 update 语句必须使用该索引,未用到该索引的语句在 SQL 层面直接报错。
|
14
jin2ml OP @nothingistrue 感谢大佬的认真回复!首先节点问题确实不对,我发完主题想了一下就感觉不太合适,放 Java 可能更合适一些。准备先睡服一下,睡服不了我就把自定义的 sql 拉出来让领导定是不是要一个一个搞。对于自定义的 mapper 拦截器的话感觉很难普遍适用
|