看了你们的文档，@RedisLock好像只能加在Controller层,如果我在service层的某个方法是同时加这两个注解就出现bug了。。。。那么事务注解 @Transactional 可能会在获取锁之前就开启了事务，从而导致无法保证先获取锁再开启事务的顺序，导致数据出现错乱问题
@RedisLock本身就是设计用在controller层的，文档的demo也是写在controller，没有写在service。
你如果把@Transactional写在controller类上或者entity类上，事务也没法生效，那是不是spring的事务设计也属于重大bug？什么功能用在哪里都是要有规则的，而不是随心所欲的。
@RedisLock和@Transactional,如果同时写在service层的某个方法上，我用jmeter测试了没有问题，那天是我看错了，请问这个作何解释？你的意思他不能用在service层，是可以用的。
controller层可以使用@Transactional，请大佬调研后再发言。
你自己都没有好好测试，就直接说框架有重大bug，你发言是否需要更加严谨？
第一个，我说的是放到controller类上面和entity类上面。而Spring 的事务管理依赖于 AOP 代理机制。@Transactional 注解会在方法执行时触发事务代理。在 Controller 类上使用时，AOP 代理可能无法覆盖到所有内部方法调用，尤其是类内部自调用的情况，这样可能导致事务不生效或无法正确回滚。再加上controller本身就不是用来操作数据库的，很多select查询你也给他加上@Transactional注解，合理吗？这样给系统带来多大的性能损耗，这完全是不可取的做法，不要为了杠而杠。
第二个，@RedisLock和@Transactional一起使用有死锁风险，@Transactional 的事务是在方法执行完毕后，才根据是否抛出异常来决定提交或回滚。但 @RedisLock 锁的释放通常是在方法结束时（或者在 finally 块中）手动释放。如果事务因为异常而回滚，但 Redis 锁在事务之前被释放，其他并发线程可能会误以为资源已释放，导致多个线程同时处理同一业务逻辑。
你不要测了一两个没有并发的情况，就觉得完全没问题然后就妄下定论了。下次你提的问题如果没有经过仔细验证或者反复修改，估计也不会再回复了。还有一个，你的账号不是商业账号，请后续辛苦一下用商业账号注册社区后再来提问商业版的问题。
扫一扫访问 Blade技术社区 移动端
加载中...
苏公网安备 32041102000998号