Jim,

I assume that you do not track J2EE world in details, so I will provide some
information about the JMS messaging that is quite common in enterprise Java.
If you know all this, please skip to the suggestions.

JMS is an abstraction of the messaging middleware that are in use for a
long, at least that was the reason why it was "invented". The idea behind it
is to allow Java applications to send and receive messages floating in the
enterprise (if I understand it correctly, JMS was never targeting desktop
systems).

JMS introduces the concept of message producer and message consumer.
Producers create messages and send them to destinations, consumers receive
and process messages. Destinations allow multiple producers and multiple
consumers. A message consists of a headers, properties and a body.

Two types of destinations are available:

- queues; in this case producers are called "senders", consumers are called
"receivers"; a message posted into a queue is guaranteed to be consumed by
only one consumer.

- topics; in this case producers are called "publishers" and consumers are
called "subscribers"; a message posted into a topic is guaranteed to be
delivered to all cosumers (a multicasting).

Each consumer can specify a message selector, syntax of which is based on
SQL92 conditional expression syntax. Message selector filters messages that
are delivered to consumers.

Also each message has two delivery modes - persistent and transient.
Transient messages are allowed to be lost during transmition. Persistent
messages must be delivered without losses.

Each message has also expiration time. Messages that were not delivered
within the specified timeout (in milliseconds) are not delivered at all.

Topic implementation must also provide a functionality to cache messages for
so-called durable subscribers. Such subscribers provide an unique ID when
connecting to a topic, and after some time they are allowed to disconnet. On
the next connection, when they provide the same unique ID, all messages that
were not yet "seen" by the subscriber are delivered to it.

Finally, JMS has a concept of transactions. Message is not considered to be
consumed until it is acknowledged. On transaction commit all messages posted
to the destination are delivered to the recepients and all consumed messages
are acknowledged. So, if some queue consumer crashes during message
processing, message is not acknowledged and will be delivered to another
consumer.

Why did I write that all above?

First of all, I want to show that event implementation is Firebird is
functionally a subset of JMS functionality (topics with transactional
message sending and auto-message acknowledgement). The only difference is
that equal messages are sent only once.

Second, I suspect that the properties described above are not unique to JMS,
but are also available in other messaging middleware. So, maybe we should
define an API for event handling, including a transaction notification and
let the messaging middleware to the rest? It can do it more effectively,
also providing a much richer functionality.

> But the real bottom line is that if the data in the message can be
> stale, a client application has to go back to the database anyway, so
> why bother to send the stale data? Perhaps you might sketch a scenario
> where stale data is useful.

No, not stale data. If a message contains some payload, client can already
make some decision on that data even without accessing the database, for
example, invalidate the cache. In that case, only one packet is sent from
server to client, not one packet with event, then request/response for
isc_dsql_exec2 (assuming that statement is prepared), request/response for
isc_dsql_fetch and isc_dsql_free to release result set. The main question is
to find the balance between the price to deliver big message and price to
maintain the log table including making network requests.

> No, not at all. I've said a million times that Interbase was designed
> for a different era, and more capable machines and networks suggest that
> all original design decisions are subject to review. This is no
> different. If there are problems that the current mechanism doesn't
> address that can be solved by an alternative mechanism without
> introducing a raft of "gotcha's", lets see what we can do.

I cannot tell that there are problems with events that current mechanism
cannot solve, but I see the way to improve it by introducing "event manager"
plugins that will deliver the event using the desired media. Some may use
UDP multicast, some may use TCP unicast, others can just proxy messages to
JMS. Idea is to let server handle data and make events management a
pluggable thing.

Roman