感谢提供解决方案解决方案是很多,但是出现这个问题我们总是要探究一下原因嘛
1 个赞
学习了,我都不知道
1 个赞
hin好
1 个赞
我之前还遇到这b问题了,生产者用主键自增策略插入了一条数据,然后消费者消费的时候查询这个主键id会有极小概率查不到,解决办法是查不到时候sleep一下,然后就查到了.
1 个赞
看着是同一类型的问题,这个思路复现问题应该也可以,等我明天的消息
1 个赞
建议有空了贴下代码细节.
1 个赞
1.找DBA确认是否是单物理库
2.看看inserData
方法的事务传播机制,可能这个方法执行完了,但是事务还没提交(被包裹在外层事务里了)
3.可能是MBP的坑,这个俺就不懂了,没用过这个高科技…
1 个赞
TransactionSynchronizationManager.registerSynchronization(new TransactionSynchronizationAdapter() {
@Override
public void afterCommit() {
// 另一个类的异步方法
asyncGet(id);
}
});
如上,用事务同步管理器试试。
3 个赞
建议看看你的插入方法
1 个赞
咋样了咋样了,有进展了吗ovo!蹲一手
蹲一个后续学习一下
3 个赞
看看设置一下隔离级别
正解,sleep 后事务提交了,自然能查出来,用事务同步管理器在事务提交后执行就可以了
就是插入慢吧。。
大佬们都好牛逼,我这个渣渣看的一愣一愣的。
蹲后续
原因就是上面大佬说的,事务未提交就去查询导致的。除了用事务管理器提交后再查询外,也可以指定之后的查询事务隔离级别为SERIALIZABLE,查询的时候会等待上次的事务提交后再查询,理论上也可以解决
学习了,真没碰到过这个问题。
insert一个事务,异步之后已经不在当前事务了,不是当前读(同一个事务内,是可以读到前面insert的数据的。),第一个事务没有commit,这个时候是读不到的。
可以看下spring 事务的源码,基于ThreadLocal的东西,好久之前看的源码忘记了,
至于为什么sleep100 后可以查到,是因为第一个事务commit了。
感谢大佬的热心帮助,原因找到了,配置文件里设置了事务规则,我不知道这回事,搞了乌龙