Ibm mobilefirst worklight适配器、会话变量：多个请求是否竞争？

问题是：适配器是线程安全的吗

我们知道，适配器可以有会话变量，因此在后续调用中可以访问由客户机的一次调用创建的状态（如果使用集群，则假定会话关联）。这里的一个例子证实了这一点

鉴于客户机代码正在对适配器进行异步调用，客户机显然有可能同时向适配器发出多个请求，因此两个这样的请求之间可能存在竞争条件，这两个请求涉及相同的会话变量

我看到两种可能性（暂时忽略集群成员之间的一致性问题）：

Worklight Server可能允许并行请求在单独的线程中运行，在这种情况下，如果会话状态变量可能存在重大不一致性，则需要同步，并且我们需要使用Java构造或数据库来实现我们必须实现的线程安全逻辑

Worklight服务器可能会对会话请求进行排队，因此适配器是线程安全的（在单个进程中），因此我们的代码稍微简单一些

---

Worklight承诺了什么？

一位Worklight架构师说：

Worklight在单独的线程中运行请求，其中全局 所有这些线程都可以作为共享脚本访问变量 对象从技术上讲，来自同一个服务器的两个并发请求 会话更新共享对象的多个字段可能会导致 对象处于不一致状态

然而，从应用程序逻辑的角度来看，这是一个罕见的问题 应用程序发送并发请求以更新 相同的数据具有不同的值。通常情况下，这是一个不希望出现的流，并且 客户端上的应用程序（通过使用繁忙的 指标等）。如有必要，开发人员可以使用简单同步 适配器代码中的构造，如维护“inProgress” 布尔全局变量，如果正在进行，则拒绝更新请求== 对

如果有一个真正的用例需要同步，它将是 很有兴趣了解它，并可能提出不同的解决方案

---

我们试图通过只返回“增量”来响应数据请求，从而减少移动设备的通信量——这需要保留一些详细的状态。这个答案证实了我们不能暂时使状态不一致，因为另一个线程可能会看到这一点。因此，我们要么需要同步，要么使用原子赋值。