最近做 SAP Fiori Elements 或 RAP 草稿应用时，经常会碰到一个很现实的问题，我们在前端看到的是一个很轻的页面，浏览器发起 OData 请求，后端返回 JSON，用户点编辑、保存、取消，界面看起来像普通 Web 应用。可是回到 ABAP 后端，事情并没有这么轻。只要业务数据被编辑，就绕不开并发控制，绕不开锁，绕不开一个更老的概念，传统事务型 ABAP 应用里的有状态编程模型。这个话题看似很底层，却直接决定 Fiori 应用的体验。比如销售订单被一个用户打开编辑时，另一个用户还能不能改。采购申请编辑到一半，浏览器关掉了，系统里的锁什么时候释放。审批单保存时，后台 COMMIT WORK 之后，之前的独占锁为什么突然没了。很多 Fiori Elements 页面上看起来只是一个小小的编辑按钮，背后其实站着 SAP 多年来形成的一整套锁机制。SAP 官方文档对传统事务型 ABAP 应用的描述很清楚，这类应用建立在 stateful programming model 之上，依赖服务器会话和应用缓冲，在用户保存或丢弃数据之前，后端可以持续保留业务对象的内存副本。这个副本的生命周期和 session 绑定，而 session 也控制悲观锁。状态从第一个请求开始，到 commit 为止；当前设置的独占锁在 commit 执行时取消，锁的生命周期也就和 ABAP session 生命周期紧密贴在一起。(