062、事务与提交COMMIT/ROLLBACK——以为数据存上了其实早就灰飞烟灭有一次在生产机排查问题一个报表程序跑完日志里明明写着“更新成功”可SE16一看目标表里连根毛都没多。翻代码前面的UPDATE、MODIFY写得有模有样可全程找不到一个COMMIT WORK。程序正常结束没有报错数据却像被风吹走了一样。后来在调试模式里手动加了个COMMIT再一跑数据稳稳落库。那一刻我意识到ABAP里的事务提交不是你想不提交就不提交而是你没提交系统就当你是“闹着玩”。数据库修改不是即时的很多零基础的同学会以为在ABAP里执行了MODIFY zdemo FROM ls_data数据就已经写进表里了。错。那只是告诉数据库“我想改”但还没“画押”。当前会话里你自己用SELECT再读能看到这个修改因为DB连接还持有这个未提交的事务。可换个会话、换个用户或者SE16重新打开就看不到。只有当COMMIT WORK发出数据库才真正把这个事务画押落盘。要是你不画押程序一结束系统自动按“撤销”处理你改的东西全成了泡影。这就是ABAP里的逻辑工作单元LUW。一个事务要嘛全部生效要嘛全部归零没有中间地带。就像转钱A账户扣了B账户没加这是在耍流氓。事务就是让这两个动作要么都成要么都废。COMMIT WORK画押最简单的场景你在程序里做了一堆新增DATA: ls_customer TYPE zcustomer. ls_customer-id 1001. ls_customer-name 张三. MODIFY zcustomer FROM ls_customer.程序跑到这里数据还在空中飘。你需要在程序结尾或者你确认这些修改要保留的地方写一句COMMIT WORK.这句话一下数据库才“啪”一声盖章行数据才算你的。别嫌我啰嗦这个坑我见过太多人踩。写的时候记着后面忘了COMMIT一调试就是半天。后来我养成习惯凡是写数据库更新先在代码里标个“COMMIT在这里”跟交警贴罚单似的。ROLLBACK WORK反悔有提交就有回滚。ROLLBACK WORK把当前事务中所有未提交的修改全部撤掉就像你刚才什么都没干。MODIFY zcustomer FROM ls_customer. IF sy-subrc 0. ROLLBACK WORK. ENDIF.实际场景更多是先做了几个修改后面处理时发现逻辑错误或者某个关键字段有问题那就直接回滚。注意回滚不是必须的程序异常终止时系统也会自动回滚。但显式写出来逻辑清晰看代码的人一眼就知道这是“有条件的反悔”不然别人还得猜你想干嘛。别小看这个COMMIT它还会触发更新任务ABAP里有个东西叫“更新任务”写法是CALL FUNCTION Z_FOO IN UPDATE TASK.这个函数里面的数据库更新不会马上执行而是挂在当前事务的延时队列里。什么时候执行就是到了COMMIT WORK的时候。你的程序里要是攒了一堆更新任务COMMIT一放全部开始干活。如果你写了ROLLBACK那这些任务也跟着烟消云散。所以你调用别人写的函数时别以为函数里面有个MODIFY、UPDATE就代表数据已经改了。得看它是普通的数据库操作还是IN UPDATE TASK。如果是后者你外面不COMMIT等于白调。这在调试很多BAPI时特别明显比如过账函数返回了一堆成功消息却啥都没有因为在BAPI的文档里就写了调用完要自己去COMMIT。COMMIT WORK AND WAIT别抢跑有时候COMMIT WORK之后你后面的代码马上要去SELECT这些刚改的数据希望读到最新值。按理说COMMIT之后数据库已经提交应该能读到。但如果你用的是更新任务IN UPDATE TASK那些函数是异步执行的——COMMIT只发了个“启动”信号不会等它们跑完。后面代码紧接着去读可能读到的还是旧数据。这种情况要用COMMIT WORK AND WAIT。COMMIT WORK AND WAIT.它会等所有更新任务执行完毕再继续。用之前想清楚不必要的等待会拖慢性能。但如果有后续逻辑强依赖更新结果别省这个WAIT。循环里COMMIT你是在找死有个经典错误在SELECT循环里一边读一边UPDATE每更新一条就COMMIT一次。看起来“保证每一条都一定能保存”实际上会导致打开游标失效程序直接崩溃或者性能差到让人想砸电脑。数据库游标在事务提交后可能是会失效的尤其Oracle或HANA上很容易报“CURSOR_INVALID”之类的错。更稳妥的做法是先把要更新的数据收集到内表循环结束后一次性MODIFY最后COMMIT一次。事务提交的次数越少锁持有时间越短系统压力越小。理解起来很简单一个人去银行办十笔业务是一起结算快还是一笔一笔排队结算快不要在可复用函数里偷偷COMMIT这个建议是写给以后写通用功能模块的。如果你的Function Module会被别的程序调用别在里面直接写COMMIT WORK。为什么因为COMMIT是整个调用链上所有未提交更改的“总放行”不是只提交你这个函数里的东西。调用方可能还有一大堆未提交的数据库修改是想自己控制回滚/提交的。你一个COMMIT下去等于替别人做了决定把人家的事务也给提交了后续人家想回滚都没戏。这就是事务边界被打破了。有经验的做法是可复用的函数只做业务处理把提交决策留给最外层调用者。BAPI倒是例外标准BAPI一般自己管理提交但那是人家定好的规矩我们写自己的FM要克制。再说说调试时遇到的坑绝招在调试器里你可以看到某句更新之后数据库未提交状态。但如果你在调试中直接跳到某行把COMMIT WORK这行跳过那程序结束照样全撤销。又或者你在测试环境里调试手动执行了COMMIT WORK那即使后面代码报错回滚数据也已经落上去了。调试器和运行环境一样都要遵守事务规则。所以别在调试时乱点不然你自以为在测试实际已经改了一堆垃圾数据。给你一个不踩坑的套路写带数据库更新的ABAP程序先想清楚三个点这个事务的“边界”在哪从哪行开始算同一笔事务到哪行截止什么时候COMMIT是程序最末还是某段逻辑结束处万一中间出错了是自动回滚还是需要显式ROLLBACK我的习惯是把COMMIT WORK放在主程序的出口处业务逻辑统统别带COMMIT。除非这个程序足够简单否则我不喜欢在子程序里COMMIT看得人脑壳疼。如果调用了BAPI那就找对应BAPI自带的提交函数像BAPI_TRANSACTION_COMMIT有现成的就用现成的。最后补一句事务提交看着是语法其实是工程决策。你提交的时机、方式决定了数据的一致性、系统的响应速度还有你自己头顶上会不会多几个事故单。多年以后当你因为一个COMMIT漏了而在生产机前怀疑人生你会感谢现在认真记笔记的自己。
062、事务与提交COMMIT/ROLLBACK——以为数据存上了其实早就灰飞烟灭有一次在生产机排查问题一个报表程序跑完日志里明明写着“更新成功”可SE16一看目标表里连根毛都没多。翻代码前面的UPDATE、MODIFY写得有模有样可全程找不到一个COMMIT WORK。程序正常结束没有报错数据却像被风吹走了一样。后来在调试模式里手动加了个COMMIT再一跑数据稳稳落库。那一刻我意识到ABAP里的事务提交不是你想不提交就不提交而是你没提交系统就当你是“闹着玩”。数据库修改不是即时的很多零基础的同学会以为在ABAP里执行了MODIFY zdemo FROM ls_data数据就已经写进表里了。错。那只是告诉数据库“我想改”但还没“画押”。当前会话里你自己用SELECT再读能看到这个修改因为DB连接还持有这个未提交的事务。可换个会话、换个用户或者SE16重新打开就看不到。只有当COMMIT WORK发出数据库才真正把这个事务画押落盘。要是你不画押程序一结束系统自动按“撤销”处理你改的东西全成了泡影。这就是ABAP里的逻辑工作单元LUW。一个事务要嘛全部生效要嘛全部归零没有中间地带。就像转钱A账户扣了B账户没加这是在耍流氓。事务就是让这两个动作要么都成要么都废。COMMIT WORK画押最简单的场景你在程序里做了一堆新增DATA: ls_customer TYPE zcustomer. ls_customer-id 1001. ls_customer-name 张三. MODIFY zcustomer FROM ls_customer.程序跑到这里数据还在空中飘。你需要在程序结尾或者你确认这些修改要保留的地方写一句COMMIT WORK.这句话一下数据库才“啪”一声盖章行数据才算你的。别嫌我啰嗦这个坑我见过太多人踩。写的时候记着后面忘了COMMIT一调试就是半天。后来我养成习惯凡是写数据库更新先在代码里标个“COMMIT在这里”跟交警贴罚单似的。ROLLBACK WORK反悔有提交就有回滚。ROLLBACK WORK把当前事务中所有未提交的修改全部撤掉就像你刚才什么都没干。MODIFY zcustomer FROM ls_customer. IF sy-subrc 0. ROLLBACK WORK. ENDIF.实际场景更多是先做了几个修改后面处理时发现逻辑错误或者某个关键字段有问题那就直接回滚。注意回滚不是必须的程序异常终止时系统也会自动回滚。但显式写出来逻辑清晰看代码的人一眼就知道这是“有条件的反悔”不然别人还得猜你想干嘛。别小看这个COMMIT它还会触发更新任务ABAP里有个东西叫“更新任务”写法是CALL FUNCTION Z_FOO IN UPDATE TASK.这个函数里面的数据库更新不会马上执行而是挂在当前事务的延时队列里。什么时候执行就是到了COMMIT WORK的时候。你的程序里要是攒了一堆更新任务COMMIT一放全部开始干活。如果你写了ROLLBACK那这些任务也跟着烟消云散。所以你调用别人写的函数时别以为函数里面有个MODIFY、UPDATE就代表数据已经改了。得看它是普通的数据库操作还是IN UPDATE TASK。如果是后者你外面不COMMIT等于白调。这在调试很多BAPI时特别明显比如过账函数返回了一堆成功消息却啥都没有因为在BAPI的文档里就写了调用完要自己去COMMIT。COMMIT WORK AND WAIT别抢跑有时候COMMIT WORK之后你后面的代码马上要去SELECT这些刚改的数据希望读到最新值。按理说COMMIT之后数据库已经提交应该能读到。但如果你用的是更新任务IN UPDATE TASK那些函数是异步执行的——COMMIT只发了个“启动”信号不会等它们跑完。后面代码紧接着去读可能读到的还是旧数据。这种情况要用COMMIT WORK AND WAIT。COMMIT WORK AND WAIT.它会等所有更新任务执行完毕再继续。用之前想清楚不必要的等待会拖慢性能。但如果有后续逻辑强依赖更新结果别省这个WAIT。循环里COMMIT你是在找死有个经典错误在SELECT循环里一边读一边UPDATE每更新一条就COMMIT一次。看起来“保证每一条都一定能保存”实际上会导致打开游标失效程序直接崩溃或者性能差到让人想砸电脑。数据库游标在事务提交后可能是会失效的尤其Oracle或HANA上很容易报“CURSOR_INVALID”之类的错。更稳妥的做法是先把要更新的数据收集到内表循环结束后一次性MODIFY最后COMMIT一次。事务提交的次数越少锁持有时间越短系统压力越小。理解起来很简单一个人去银行办十笔业务是一起结算快还是一笔一笔排队结算快不要在可复用函数里偷偷COMMIT这个建议是写给以后写通用功能模块的。如果你的Function Module会被别的程序调用别在里面直接写COMMIT WORK。为什么因为COMMIT是整个调用链上所有未提交更改的“总放行”不是只提交你这个函数里的东西。调用方可能还有一大堆未提交的数据库修改是想自己控制回滚/提交的。你一个COMMIT下去等于替别人做了决定把人家的事务也给提交了后续人家想回滚都没戏。这就是事务边界被打破了。有经验的做法是可复用的函数只做业务处理把提交决策留给最外层调用者。BAPI倒是例外标准BAPI一般自己管理提交但那是人家定好的规矩我们写自己的FM要克制。再说说调试时遇到的坑绝招在调试器里你可以看到某句更新之后数据库未提交状态。但如果你在调试中直接跳到某行把COMMIT WORK这行跳过那程序结束照样全撤销。又或者你在测试环境里调试手动执行了COMMIT WORK那即使后面代码报错回滚数据也已经落上去了。调试器和运行环境一样都要遵守事务规则。所以别在调试时乱点不然你自以为在测试实际已经改了一堆垃圾数据。给你一个不踩坑的套路写带数据库更新的ABAP程序先想清楚三个点这个事务的“边界”在哪从哪行开始算同一笔事务到哪行截止什么时候COMMIT是程序最末还是某段逻辑结束处万一中间出错了是自动回滚还是需要显式ROLLBACK我的习惯是把COMMIT WORK放在主程序的出口处业务逻辑统统别带COMMIT。除非这个程序足够简单否则我不喜欢在子程序里COMMIT看得人脑壳疼。如果调用了BAPI那就找对应BAPI自带的提交函数像BAPI_TRANSACTION_COMMIT有现成的就用现成的。最后补一句事务提交看着是语法其实是工程决策。你提交的时机、方式决定了数据的一致性、系统的响应速度还有你自己头顶上会不会多几个事故单。多年以后当你因为一个COMMIT漏了而在生产机前怀疑人生你会感谢现在认真记笔记的自己。
