首页
沸点
课程
数据标注
HOT
AI Coding
更多
直播
活动
APP
插件
直播
活动
APP
插件
搜索历史
清空
创作者中心
写文章
发沸点
写笔记
写代码
草稿箱
创作灵感
查看更多
登录
注册
确定删除此收藏集吗
删除后此收藏集将被移除
取消
确定删除
确定删除此文章吗
删除后此文章将被从当前收藏集中移除
取消
确定删除
编辑收藏集
名称:
描述:
0
/100
公开
当其他人关注此收藏集后不可再更改为隐私
隐私
仅自己可见此收藏集
取消
确定
事务
订阅
用户1237294505774
更多收藏集
微信扫码分享
微信
新浪微博
QQ
4篇文章 · 0订阅
@Transactional事务,太坑了!
前言 对于从事java开发工作的同学来说,Spring的事务肯定再熟悉不过了。 在某些业务场景下,如果一个请求中,需要同时写入多张表的数据。为了保证操作的原子性(要么同时成功,要么同时失败),避免数据
头疼,又遇到大事务问题了。。。
前言 最近有个网友问了我一个问题:系统中大事务问题要如何处理? 正好前段时间我在公司处理过这个问题,我们当时由于项目初期时间比较紧张,为了快速完成业务功能,忽略了系统部分性能问题。项目顺利上线后,专门
我又被Spring的事务坑了,用户兑奖之后,什么东西都没收到!!
没错,我又被事务坑了! 即上次的mq发送消息之后,业务代码回滚,导致发了一条中奖消息给用户!!,这次又被spring的事务坑了 兑奖接口,我们先改变了这条数据的状态为已兑奖,之后居然回滚了。。。
@Transactional注解的一个很容易被忽略的错误用法
@Transactional注解的一个很容易被忽略的错误用法 今日审查代码时发现对@Transactional注解的一个如下用法: 这段代码的逻辑是在StockService.outStock方法中调