# 事务提交时原子写审计日志：commit里调存储过程，业务和日志同生共死

事务提交时原子写审计日志：commit里调存储过程，业务和日志同生共死

文章标签：#java #政务 #审计日志 #事务管理 #MyBatis #自研框架

非科班野生程序员，深耕政务信息化20年。从VC到PB再到Java，自研框架browise也打磨了十几年。最近整理框架代码，发现不少有趣的决策，写出来和大家聊聊。最后感谢豆包、智谱、OpenCode，决策是我做的，代码是我搓的，文字是他们总结的。

一、政务审计的核心痛点：原子性

政务系统有强合规、强审计要求：谁、在什么时间、对哪条数据、做了什么操作、结果如何，必须完整留痕、不可篡改、不可丢失。

最大难点：如何保证业务数据与审计日志的强一致、同生共死

• 业务提交成功 → 日志必须落库
• 业务回滚 → 日志必须一起消失
• 绝不允许：业务成功、日志丢失；或日志写入、业务回滚

常见方案的缺陷

• 双事务分别写：无原子性，极易不一致
• 分布式事务（XA）：太重、性能差、配置复杂
• 消息队列异步写：有延迟，不满足实时审计
• 业务代码里硬编码写日志：侵入强、易漏、难维护

我的极简方案

在同一个事务、同一个数据库连接内：commit 阶段先写审计日志，再提交事务
日志与业务天然同事务、同原子，不引入任何中间件，轻量、可靠、合规。

二、核心设计思路

1. 业务增删改执行完毕，但事务未提交
2. 重写commit()方法：先调用审计存储过程，再执行事务提交
3. 存储过程与业务共用SqlSession，同一连接、同一事务
4. 日志写入失败 → 抛异常 → 事务不提交 → 整体回滚
5. 日志写入成功 → 执行session.commit()→ 业务与日志一起落库

一句话：日志写不成功，业务绝对不提交。

三、完整优化代码（可直接上线）

1. BusinessSession 事务会话封装

importorg.apache.ibatis.session.SqlSession;importjava.util.HashMap;importjava.util.Map;/** * 事务会话封装：commit 时原子写入审计日志 * 保证业务与审计日志同事务、同生共死 * @author yuhou25 */publicclassBusinessSessionimplementsAutoCloseable{// 操作唯一IDprivateStringBAZ001;// MyBatis 会话（同一数据库连接）privatefinalSqlSessionsession;// 是否开启审计日志privatebooleansaveLog=true;// 当前登录用户privateUserdao;// 业务类型/交易类型privateStringBAZ099;privateStringBAZ098;/** * 构造方法 * @param isModify 是否为修改类操作（是则生成操作ID） */publicBusinessSession(booleanisModify)throwsUtilException{this.session=DBUtil.getSqlSession();if(isModify){// 生成全局唯一操作序列号this.BAZ001=SystemUtil.getSeq("S_SEQ_BAZ001");}}/** * 【核心】重写提交：先写审计日志，再提交事务 */publicvoidcommit()throwsUtilException{// 开启审计时，先调用存储过程写日志if(saveLog){Map<String,Object>param=newHashMap<>();param.put("PRM_OPERATEID",BAZ001);param.put("PRM_AAE011",dao==null?"system":dao.getPsn_name());param.put("PRM_BAZ099",BAZ099);param.put("PRM_BAZ098",BAZ098);// 存储过程内部取系统时间param.put("PRM_APPCODE",0);param.put("PRM_ERRORMSG","");try{// 调用审计存储过程（同事务）session.selectOne("com.browise.core.util.mapper.sysUtilMapper.DO_TRANSACTION",param);}catch(Exceptione){thrownewUtilException("审计日志写入异常："+e.getMessage(),-100);}// 判断存储过程返回码intappCode=Integer.parseInt(String.valueOf(param.get("PRM_APPCODE")));StringerrorMsg=String.valueOf(param.get("PRM_ERRORMSG"));if(appCode<0){thrownewUtilException("审计日志校验失败："+errorMsg,appCode);}}// 日志校验通过，正式提交事务session.commit();}/** * 回滚：业务与日志一起回滚 */publicvoidrollback(){session.rollback();}/** * 关闭会话 */@Overridepublicvoidclose(){session.close();}// ------------------- 工具方法 -------------------public<T>TgetMapper(Class<T>clazz){returnsession.getMapper(clazz);}publicvoidsetSaveLog(booleansaveLog){this.saveLog=saveLog;}publicvoidsetUser(Useruser){this.dao=user;}publicvoidsetBizType(StringBAZ099,StringBAZ098){this.BAZ099=BAZ099;this.BAZ098=BAZ098;}}

2. MyBatis Mapper 调用存储过程

<!-- sysUtilMapper.xml --><mappernamespace="com.browise.core.util.mapper.sysUtilMapper"><selectid="DO_TRANSACTION"statementType="CALLABLE"parameterType="map">{call PKG_AUDIT.DO_TRANSACTION( #{PRM_OPERATEID,mode=IN,jdbcType=VARCHAR}, #{PRM_AAE011,mode=IN,jdbcType=VARCHAR}, #{PRM_BAZ099,mode=IN,jdbcType=VARCHAR}, #{PRM_BAZ098,mode=IN,jdbcType=VARCHAR}, #{PRM_APPCODE,mode=OUT,jdbcType=INTEGER}, #{PRM_ERRORMSG,mode=OUT,jdbcType=VARCHAR} ) }</select></mapper>

3. 标准业务调用模板

publicvoidupdateBusiness(DataVOdata){// 开启修改操作会话try(BusinessSessionbs=newBusinessSession(true)){// 设置当前用户、业务类型bs.setUser(UserContext.getCurrentUser());bs.setBizType("USER_MANAGE","MODIFY");// 执行业务逻辑MyMappermapper=bs.getMapper(MyMapper.class);mapper.updateById(data);// commit 自动写审计日志，同事务提交bs.commit();}catch(UtilExceptione){// 异常自动回滚：业务 + 日志一起撤销log.error("业务执行失败",e);throwe;}}

四、存储过程 DO_TRANSACTION 做了什么

Oracle 存储过程，与业务同事务：

1. 接收操作ID、操作人、业务类型、交易类型
2. 从临时表读取本次操作影响的表、主键、变更前后数据
3. 组装审计日志，写入正式审计表
4. 通过PRM_APPCODE返回结果：0=成功，<0=失败
5. 异常时返回错误信息，让 Java 层触发回滚

关键点：存储过程不加自治事务，完全依附于业务事务，保证强一致。

五、关键细节：saveLog 开关

privatebooleansaveLog=true;

• 默认开启审计
• 日志本身、监控、定时任务等不需要递归审计的场景，可关闭

// 示例：日志工具类不记录自身session.setSaveLog(false);

六、为什么这套方案能拿90+

1. 强原子性：同连接、同事务，业务与日志绝对一致
2. 零侵入：业务代码只写逻辑，不用关心日志
3. 零依赖：不引入MQ、XA、Seata等中间件
4. 高性能：无分布式开销，一次提交完成
5. 合规可追溯：满足政务、等保、审计要求
6. 易维护：统一收口，一处修改，全局生效

七、对比传统方案

八、小结

这套审计日志方案仅130行左右核心代码，靠commit 阶段写入+同事务执行，实现业务与审计日志的强一致。
没有花里胡哨的架构，没有复杂中间件，极简、稳定、能过审，非常适合政务、金融、医疗等高合规场景。

审计日志的写入时机大家是怎么处理的？评论区聊聊。