我们正在尝试实现重试逻辑以从 Azure 环境中的瞬态错误中恢复。
我们正在使用长时间运行的会话来跟踪并在应用程序事务结束时提交所有更改（可能分布在多个 Web 请求中）。一路上，我们需要从数据库中获取额外的数据。我们的主要问题是我们不能轻易地从 db 错误中恢复，因为我们不能“重播”所有用户操作。
到目前为止，我们使用了简单的恢复算法：
- 尝试在长时间运行的会话中执行操作
- 如果出现错误，请关闭会话，打开一个新会话并将实体合并到其中
- 重试操作
就时间而言，这是非常昂贵的方法（合并对于大型实体层次结构来说真的很长）。所以我们想稍微优化一下。
我们希望在单独的会话中执行查询操作（以保持长时间运行一个未触及和安全），并在成功后将结果合并回长时间运行的会话。重试在这里相对简单——我们只需要打开新会话并再次运行查询。但是，使用这种方法，我们在初始化惰性属性/集合时会遇到问题：
- 如果我们在单独的会话中执行此操作，我们需要将结果合并回来（很多实体），但合并可能会失败并中断长时间运行的会话
- 我们尝试了不同的方式将原始实体“移动”到不同的会话，加载详细信息并将其返回，但没有成功（驱逐、复制等）
有一个已知的声明，如果出现异常，会话应该被丢弃。但是，该示例显示了写操作。阅读的人仍然如此吗？我的意思是如果我保证没有数据被写回数据库，我可以重复使用同一个会话来再次运行查询吗？
您对长时间运行的会话的重试逻辑还有其他建议吗？