在 SAP Gateway 项目里，有一类性能问题很有代表性。一个 OData 请求本身执行得并不复杂，真正昂贵的是请求进入业务框架以后，需要初始化大量数据、读取 Customizing、构造业务对象、建立应用级 Buffer，甚至调用历史比较久的 Backend Framework。第一次请求可能需要两三秒，紧接着发出的第二个请求其实可以复用刚才准备好的数据，却因为传统 OData 请求按照无状态方式运行，又把初始化过程完整执行了一遍。Soft State就是 SAP Gateway 为这类场景准备的一种特殊运行模式。SAP 官方对它的定位相当明确。启用Soft State后，SAP Gateway Runtime 可以让多个连续请求尽可能运行在同一个 ABAP Application Server Session 中，因此一些已经装载到应用服务器会话中的资源能够被后续请求继续复用。它看起来有一点像 Stateful Processing，但又没有把 OData 服务真正改造成 Stateful Application。会话超时以后，框架不会要求客户端把整个业务流程推倒重来，而是可以建立新的 Application Server Session，并继续按照普通请求方式处理。对 OData Consumer 来说，会话的这种变化应当是透明的。理解这一点非常重要。Soft State不是用来保存跨请求事务的，也不是让两个 HTTP 请求共享一个数据库 LUW，更不能依靠它维持数据库锁、未提交数据或者某个只能存在于当前 Internal Session 中的关键业务状态。SAP 官方明确要求，即使启用了