Siebel 8 竞争条件
想象一下以下设置
- 任务列表中的一组 n 个独立任务必须在 Siebel 中完成
- 可以处理任务 a、b 等通过单独的线程
- 当一个线程启动时，工作流会记录所有 n 个任务的状态
- 线程继续完成并最终将 JMS 消息发送到队列
我们有以下问题：
- 线程 1 适用于任务 a完成其工作并将任务a标记为已关闭
- 同时，处理任务b的线程2也完成它的工作并将任务b标记为关闭
- 两条JMS消息被放置在队列中并发送到另一个后端系统
- 问题是：第一条JMS消息表明任务列表为
a=close b=open并且第二条 JMS 消息显示a=open b=close - 任务可以由 Siebel 用户合法地重新打开（假设出于欺诈检查目的）
- 后端系统以任意顺序接收两条 JMS 消息，因为中间件不保证顺序
- 后端系统收到一条 JMS 消息，内容为
close,open，不久之后又收到另一条消息，内容为open,close。这可以按任何顺序发生，但结果是相同的。后端系统似乎认为，在 Siebel 中的所有任务中，整个任务列表尚未关闭（本例中的a 和b） 我被
告知在 Siebel 中无法提交数据库来修改工作流线程中正在执行的任务的状态只能发生在工作流程的最后。这意味着在 JMS 消息以误导性状态发送出去之后至关重要。这显然是因为需要在出现错误时回滚工作流程。
问题： 上述说法是否真的意味着该问题在 Siebel 中永远无法解决？如果没有，那么有人可以告诉我是否可以在 Siebel 中修复此问题，以便发送带有正确任务状态的 JMS 消息。我天真地认为这是使用信号量解决的，但说实话，我被宠坏了，因为我从来没有处理过信号量，而且我肯定不知道这个概念是否存在于 Siebel 中。有什么帮助吗？
Imagine the following set up
- A set of n independent tasks in a task list must be completed in Siebel
- Tasks a, b etc can be worked on by separate threads
- When a thread starts the work flow records the states of all n tasks
- The threads continue to completion and eventually end up sending a JMS message to a queue
We have the following problem:
- Thread 1 that works on task a completes its work and marks task a as closed
- At the same time thread 2 that works on task b also completes its work and marks task b as closed
- Two JMS messages are placed on the queue and sent to another back end system
- Here's the problem: The first JMS message says that the state of the task list is
a=closed b=openand the second JMS message saysa=open b=closed - Tasks can legitimately be re-opened by a user of Siebel (let's say for fraud checking purposes)
- The back end system receives the two JMS messages in any order since the middleware does not guarantee ordering
- The back end system receives one JMS message saying
closed,openand another shortly afterwards that saysopen,closed. This could happen in any order but the result is the same. It appears to the back end system that the entire task list has not been closed whilst in Siebel all tasks (a and b in this example) have been closed
I am told that there is no way in Siebel that the commit to the database that modifies the state of the tasks being acted upon in the workflow thread can only happen at the very end of the work flow. That means crucially after the JMS messages have been sent out with the misleading state. This is apparently because of the need to roll back a workflow upon error.
Questions: Is the above statement true meaning that this problem can never be solved in Siebel? If not then can someone tell me whether it is possible to fix this in Siebel such that a JMS message is sent with the correct state of the tasks. I naively think this is solved using semaphores, but truth be told I've been spoiled in the sense I've never had to deal with semaphores and I sure don't know if that concept even exists in Siebel. Any help?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
在数据提交到数据库之前无法读取数据，只能控制时序。
使用业务服务同步调用工作流，或者使用业务服务代替工作流，并在数据库提交后发送 JMS 消息。 从业务服务调用工作流程的说明。
Can't read data before it's committed to the database, can only control the timing.
Use a business service to call workflow(s) synchronously, or use business service instead of workflow, and send JMS message after database commit. Instructions to call a workflow process from business service.