Worklight JSON 存储，我们可以获取竞争条件吗？答案

【问题标题】：Worklight JSON Store, can we get race conditions?Worklight JSON 存储，我们可以获取竞争条件吗？
【发布时间】：2014-05-08 22:14:05
【问题描述】：

Windows（同事）和 Mac（我）上的 Worklight 6.1，构建了一个用于 Android 设备的混合应用程序，但为了加快开发速度，我们在桌面上的 Chrome 浏览器中作为移动 Web 应用程序进行了初步测试。

我们得到一个奇怪的症状，我正试图将其细化为可重现的测试用例。我想我在进入调试器并让它运行时看到了不同的行为。想在我继续之前检查某种编码模式是否可能是导致症状的原因。

基本问题：我们是否应该等待 JSONSTore 请求返回的承诺解决，然后再发出另一个请求？更多解释如下。

总体意图是将一些数据加载到 JSONStore 中，如果记录已经存在，则使用一些智能替换/合并操作。伪代码：

  for each record retrieved from back-end

        if ( record already present in Store )
              do some data merging 
              replace record
        else
              add record

应用程序代码实际上是这样工作的，只考虑add()的情况，问题在store为空时表现出来，所有记录都需要添加

  for each record to add 
        addPromise = store.get().add(record);
        listOfPromises.insert(addPromise);

  examine the list of promises recording any errors

在发出下一个添加请求之前，没有“等待”添加完成。因此，实际上我们已经启动了一组“并行”添加，无论这在 Chrome 中的 JavaScript 中可能意味着什么。

代码似乎运行良好，没有报告错误。在 android 设备上它工作可靠。在正常运行的 Chrome 中（没有单步调试器），我们最终没有报告错误，但只插入了一条记录 - 确实好像已经拍摄了初始“空”存储的快照，并且每次添加都在那个“空”副本上工作.

写完这篇文章后，我现在非常确信上述编码模式容易受到某种竞争的影响，更好的方法是构建要添加的文档列表并将它们插入到单个操作中。

【问题讨论】：

标签： ibm-mobilefirst jsonstore

【解决方案1】：

稍后会有更详细的答案，但我现在知道了

上面描述的编码模式容易受到一种种族和更好的方法是建立一个要添加的文档列表和将它们插入单个操作中。

是真的。在浏览器中，JSONStore 确实要求我们在发出另一个请求之前等待一个请求的结果。推荐的方法是

var dataToAdd = buildArrayOfDataToAdd(responseFromServer);
var dataToReplace = buildArrayOfDataToReplace(responseFromServer);

jsonstore.add( dataToAdd ).then( function() { jsonstore.replace( dataToReplace); })

【讨论】：