使用 DBMS_AQ.POST 的示例及其实用程序的说明
DBMS_AQ 包有一个称为 POST 的方法。
文件说，
此过程发布到列表 匿名订阅，允许所有 已注册的客户 订阅以获取通知 持久消息。 这个功能是 缓冲消息不支持。
和
此调用提供了最大努力 保证。 通知将发送至 最多注册一次客户。 这 call 主要用于轻量级 通知。 如果应用程序需要 更严格的保证，那么就可以 加入队列。
我理解所有单词，但我看不出非保证消息传递的目的。 我排队买东西是因为我需要它才能到达某个地方。 也许只是我的企业没有这方面的用例。 我想知道这种技术有哪些用例。
The DBMS_AQ package has a method called POST.
The documentation says,
This procedure posts to a list of
anonymous subscriptions, allowing all
clients who are registered for the
subscriptions to get notifications of
persistent messages. This feature is
not supported with buffered messages.
and
This call provides a best-effort
guarantee. A notification goes to
registered clients at most once. This
call is primarily used for lightweight
notification. If an application needs
more rigid guarantees, then it can
enqueue to a queue.
I understand all of the words but I do not see a purpose for non-guaranteed messaging. I queue something because I need it to get somewhere. Maybe it's just that my business doesn't have a use-case for this. I'd to know what use-cases you have for such a technology.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
首先想到的是您可能有大量对数据库信息感兴趣的客户端应用程序。 某些系统会触发一个事件，用有用但不那么重要的信息（例如向用户显示的表中的总行数）更新数据库。
然后它想要将此消息广播给客户端，但如果客户端确实很忙（或短暂离线 - 例如网络断开连接），则可以使用此方法来丢弃不重要的消息。 在某些情况下，这可能是最好的方法，就好像客户端处于离线状态时，客户端在重新连接时可能会再次主动查找所有信息。
虽然有一些用例，但我猜它们比保证交付要少得多——就像 TCP 的使用似乎比 UDP 多得多。
The first that springs to mind is that you may have a large number of client applications interested in the DB information. Some system triggers an event that updates the database with useful, but not so important information (e.g. total count of rows in a table that is shown to the user).
It then wants to broadcast this to the clients, but if a client is really busy (or offline briefly - e.g. network disconnect), this approach can be used to drop the unimportant message. This may be the best approach to take in some situations as if they are offline the client may when reconnecting actively look up all the information again.
While there are use cases, I would guess they're much less common than guaranteed delivery - just like TCP seems to be used significantly more than UDP.