我们已经注意到，当DevForce请求超时时，它会自动重试。这种行为在这里的论坛上也有提到。在那个论坛帖子中，建议的解决方案是增加超时时间，试图完全避免这个问题。对我们来说，这不是一个真正可行的解决方案。有一些操作我们知道会超时，增加超时不是一个可接受的解决方案。
更糟的是，如果调用是存储过程查询或InvokeServerMethod调用，则调用很可能不是幂等的，因此再次尝试它是不安全的，并且很可能最终弊大于利。在我们的应用中，我们已经开始遇到这样的情况，这给我们带来了很大的痛苦。一个简单的例子是:我们调用一个存储过程来创建一个项目的副本。如果复制花费的时间太长，它会一直被重试，但这意味着我们有3个复制操作都是并行进行的。最终的结果是最终用户得到一个错误(因为第三个重试仍然超时)，但(最终)将有三个项目的副本(存储过程最终将完成-重试逻辑似乎不会取消以前的请求-我甚至不确定这种取消是否可能)。这是一个比较好的例子——在其他情况下，重试操作可能会导致更严重的问题。
我从6.1.6发布说明中看到，DevForce不再执行自动重试保存。我真的希望看到这种行为扩展到StoredProcedureQueries和InvokeServerMethods。对于正常的EntityQuery操作(甚至可能是Connect/Disconnect调用)，我对rety很满意。如果这不是DevForce核心可以改变的东西，有没有办法让它可配置，或者提供一些自定义的方式让我们注入控制它的代码?
通信失败的自动重试行为在现在可用的7.2.4版本中是可配置的。有关使用信息，请参阅发行说明。