wuhunyu

使用乐观锁更新的话，如果出现了并发有概率出现部分用户无法更新成功的情况，也就是数据库返回受影响行数为 0 ，这个时候需要提示用户修改失败，并要求重新刷新表单数据之后重新提交修改，并发量大的情况下，用户仍然有可能第二次提交也是失败的

使用锁的话，大概率是可以更新成功的，但可能遇到的问题有，并发量大时可能会等待，表现为用户提交表单等待的时间会长一点或者直接等待超时（这种情况下，有可能修改成功，也可能失败）。此外还有一个问题是，后提交的用户有可能会把之前提前的信息给覆盖掉（比如 #13 提到的问题）

如果按照锁升级策略来看的话，是否可以考虑如下策略
默认使用乐观锁，当出现冲突时，也就是数据库返回受影响行数为 0 时，进入重锁模式，重锁模式释放完毕之后，再做一个判断，如果当前没有使用资源的线程，则切换回乐观锁模式

@fantasy0v0
嗯，我之前没有使用 `spring-boot-starter-jooq` 启动器，而是单独引入的 `jooq` 依赖。直接删除那部分配置肯定是不行的。

换成引入 `spring-boot-starter-jooq` 之后，把自己的配置删除确实可以了。

不过我发现另一个问题是默认情况下使用 spring 的事务是正常的，但换用 jooq 自身的事务 api （比如 `dslContext.transaction`），就出现异常了。具体异常提示是 `Cannot use ContextTransactionalCallable with TransactionProvider of type class org.springframework.boot.autoconfigure.jooq.SpringTransactionProvider`。此时我还需要手动将 `org.jooq.TransactionProvider` 的实现从 `org.springframework.boot.autoconfigure.jooq.SpringTransactionProvider` 换成 `org.jooq.impl.ThreadLocalTransactionProvider` 才行

@fms 好的，明天摸鱼的时候 debug 调试看看

@Gilgamesh7 不管是 jooq 还是 mybatis ，示例中都是使用 spring 的 @Transactional 注解来声明事务的。我的代码写的有一些歧义，但事务应该都要能正常生效才对。自调用是可能导致事务失效，但自调用的方法自身是已经开启了事务的，那么事务就应该继续生效才对。现在我换用了 jooq 的事务方法使用编程式事务，测试代码如下
```java
@Test
@DisplayName("jooq 编程式事务")
@Order(5)
public void testJooqExceptionByProgrammatic() {
TUser tUser = null;
try {
// 开启事务
tUser = dslContext.transactionResult(() -> {
return userService4Jooq.insertRetuningThrow(userId4Jooq, userName4Jooq);
});
} catch (Exception e) {
// 不需要关注此异常
}

Assertions.assertNull(tUser, "事务回滚失败");
}
```
事务可以正常运行，插入的结果正常回滚了

但声明式事务还不清楚是什么原因失效了

我遇到一个问题是，我在发起一个堆的提问之后，发现之前的一个提问是我发出的指令有问题，这个时候如果我再发起一个撤回提问往往都是无法达到我想要的撤回效果的。也就是说，我以为的撤回是把之前的一个操作剔除掉，但 ai 的操作往往是通过增量动作去尝试到达我要的撤回效果

看样子是纯前端的工具，不过就像是网友们说的，idea 中已经有满足你需求的插件了，甚至还少一次复制类的动作。不过还是提几个可优化的点
1. 给出的 json 输出中，未适配的数据类型不能给出正确的值。基本的 Long ，Integer 得做一下适配吧，我不信作者的类中没用到的基本数据类型的包装类
2. 静态字段也输出在 json 中。对象实例在序列化后不会包含静态属性。其他的比较少见的 transient ，以及 jackson 的 @JsonIgnore 都没有做忽略
3. 无法读取类的上下文依赖情况。试想一下这种情况，一个用户类中，有拥有的角色类属性，所属部门类属性等等，在这个工具中，如果要被正确识别角色属性和部门属性，要把用户类，角色类和部门类都复制出来，才能生成正确的 json 输出。这个场景应该是比较常见的。如果是在 idea 的插件中，可以读取到项目的上下文环境。但在作者的这个工具中，需要使用者把这些类都复制出来才行。这是一个硬伤

@leeonsoft Termius 不满足题主说的第 3 点，而且收费也太贵了，一个月 $10 ，如果只需要最基本的 ssh 使用需求，倒是可以用

有一说一，6.1 寸的手机我都嫌大。近一年内应该没有低于这个尺寸的手机上市吧。我知道的低于 6.1 寸的还在售新机的就只有 iPhone se 了，最后一代 iPhone 13 mini ，官网都不卖，只能找第三方了。关键是我现在用的 iPhone 13 已经比较卡了，猜测 iPhone 13 mini 只会更卡。小屏意味着 续航低 或者 性能低，估计近几年都打破不了这个魔咒

还有一个问题是，如果要切换数据库引擎，不知道题主的系统做新数据库的适配有多大的成本，这也是要考虑的，而且迁移到新的数据库引擎，旧数据是不是也要迁移过去，也是一个问题。所以我认为，换数据库引擎应该是最后应该考虑的，因为迁移的成本可能并不小