在 SAP S/4HANA 的 OData API 中，有一个很容易被忽略、却直接关系到数据正确性的细节。以当前 SAP 官方 Sales Order A2X OData V4 API 为例，当客户端通过PATCH修改销售订单时，请求通常需要携带当前订单的ETag，并通过 HTTP 的If-Match条件提交修改。这个ETag可以从之前的响应 Header 或@odata.etag中取得。如果读取订单以后，后台订单已经被其他请求修改，那么原来的ETag就不再代表服务器上的最新版本，此时服务不会简单地拿新请求覆盖数据库里的内容，而是把这次更新识别为并发冲突。这正是 SAP RAP 里 concurrency control 要解决的问题。数据库事务并发真正危险的地方，并不只是两个人在完全相同的一毫秒执行UPDATE。在 Web 应用、SAP Fiori Elements、OData、移动客户端以及系统集成环境中，更常见的问题发生在「读取」和「写入」之间。某个客户端读取了一份业务数据，在浏览器中停留几十秒甚至几分钟，此时另一个客户端已经把后台数据修改了。原客户端仍然拿着几分钟前看到的数据执行保存。如果系统毫无检查地接受这次请求，后一次提交很可能把前一次已经生效的修改覆盖掉。SAP RAP 的 concurrency control 就是为了解决这种情况。SAP 当前 RAP 文档把并发控制分为两个互补机制，Optimistic Concurrency Contro
在 SAP S/4HANA 的 OData API 中，有一个很容易被忽略、却直接关系到数据正确性的细节。以当前 SAP 官方 Sales Order A2X OData V4 API 为例，当客户端通过PATCH修改销售订单时，请求通常需要携带当前订单的ETag，并通过 HTTP 的If-Match条件提交修改。这个ETag可以从之前的响应 Header 或@odata.etag中取得。如果读取订单以后，后台订单已经被其他请求修改，那么原来的ETag就不再代表服务器上的最新版本，此时服务不会简单地拿新请求覆盖数据库里的内容，而是把这次更新识别为并发冲突。这正是 SAP RAP 里 concurrency control 要解决的问题。数据库事务并发真正危险的地方，并不只是两个人在完全相同的一毫秒执行UPDATE。在 Web 应用、SAP Fiori Elements、OData、移动客户端以及系统集成环境中，更常见的问题发生在「读取」和「写入」之间。某个客户端读取了一份业务数据，在浏览器中停留几十秒甚至几分钟，此时另一个客户端已经把后台数据修改了。原客户端仍然拿着几分钟前看到的数据执行保存。如果系统毫无检查地接受这次请求，后一次提交很可能把前一次已经生效的修改覆盖掉。SAP RAP 的 concurrency control 就是为了解决这种情况。SAP 当前 RAP 文档把并发控制分为两个互补机制，Optimistic Concurrency Contro
平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测)
