3

我正在编写一个工作流系统，该系统在每一步都完全由明确的人机交互驱动。也就是说，将任务分配给一个人，该人从几个有限的选项中进行选择{批准，拒绝，转发}，然后将其发送给下一个人或终止。

只是好奇 Oracle Streams/AQ 是否可以提供由常规 Web 应用程序代码管理的平面表所提供的任何东西。每个动作之后的处理量是相当有限的，而且处理量也不是很高，因此实际上不需要通过将它们放入队列来限制它们。引入队列结构有什么好处，或者对我的情况来说它是不是有点矫枉过正？

4

3 回答 3

4

排队的最大优势是它可以使原本非常困难的并发问题（显示一个且只有一个线程用于处理该记录）变得非常容易。如果没有排队，您可以尝试但不能确保这种行为，并且您最终必须进行大量中间状态更新并检查失败的线程。

SKIP LOCKED在 10g 及更低版本中，Oracle 使用不允许最终用户的语法实现了事务出队操作。在 11g 中，该语法已被公开以允许人们解决该问题（显示下一条记录）而不需要 AQ 实现。

AQ 的第二个优点是队列清理是异步的。

AQ 的最大缺点是它的大小和维护——一个最终为单个持久队列/主题创建了 7 个表/IOT 的顺序，并且一个不能直接维护这些数据库对象，但你必须通过以下方式进行维护DBMS_AQ 和 DBMS_AQADM 包。

于 2010-03-15T22:47:41.963 回答
3

排队系统有益的原因有很多，但我不确定它们是否适用于您的情况。听起来您有一个系统，所有系统都存储在一个数据库中。因此，我认为排队不会比普通桌子提供任何优势。

AQ 提供好处的情况包括： - 作为不同系统（多个数据库）相互通信的机制

  • 当您有松散耦合的系统时 - 向未知数量的订阅者发送消息的生产者

作为在单个系统中管理状态的一种方式，例如您所描述的，我认为 Streams/AQ 将是矫枉过正。

于 2010-03-15T21:57:19.347 回答
0

如果您的应用程序的容量真的很小并且假设几分钟的延迟是可以接受的，我会避免两者并使用老式触发器来填充我自己的日志记录表。然后我会用 pl 作业处理这些。所有这些都是为了避免 AQ 带来的额外功能/复杂性。

于 2010-10-27T02:33:05.410 回答