views:

145

answers:

1

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.

A: 

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.

Jamie Love
Accepting cuz it's close and no one else seems to care