【发布时间】：2012-02-28 07:32:08
【问题描述】：
想象一下下面的设置
- 任务列表中的一组 n 个独立任务必须在 Siebel 中完成
- 任务 a、b 等可以由单独的线程处理
- 当一个线程启动时，工作流会记录所有 n 个任务的状态
- 线程继续完成并最终将 JMS 消息发送到队列
我们有以下问题：
- 处理任务 a 的线程 1 完成其工作并将任务 a 标记为 已关闭
- 同时在任务b上工作的线程2也完成了它的工作并将任务b标记为关闭强>
- 两条 JMS 消息被放入队列并发送到另一个后端系统
- 问题出在：第一条 JMS 消息说任务列表的状态是
a=closed b=open，第二条 JMS 消息说a=open b=closed - Siebel 用户可以合法地重新打开任务（假设用于欺诈检查）
- 由于中间件不保证顺序，后端系统以任意顺序接收两条 JMS 消息
- 后端系统收到一条 JMS 消息，显示
closed,open，不久之后又收到一条显示open,closed的消息。这可能以任何顺序发生，但结果是相同的。 向后端系统显示整个任务列表尚未关闭，而在 Siebel 中的所有任务（本例中为 a 和 b）已关闭
有人告诉我，在 Siebel 中，无法仅向数据库提交修改工作流线程中正在执行的任务的状态在工作流程的最后。这意味着在带有误导性状态的 JMS 消息发出之后至关重要。这显然是因为需要在出错时回滚工作流。
问题：上述陈述是否真的意味着这个问题在 Siebel 中永远无法解决？如果没有，那么有人可以告诉我是否可以在 Siebel 中解决此问题，以便发送带有正确任务状态的 JMS 消息。我天真地认为这是使用信号量解决的，但说实话，我已经被宠坏了，因为我从来没有处理过信号量，我肯定不知道这个概念是否存在于 Siebel 中。有什么帮助吗？
【问题讨论】：
标签： asynchronous race-condition siebel