Roman Rokytskyy wrote:

>This is how messaging, at least JMS messaging works. Application posts a
>message, messaging subsystem ensures that messages are delivered reliably to
>one or all registered listeners (depends whether we talk about queues or
>topics). Message listener is called from another thread. In EJB that means
>that separate thread is also an independent transaction context. Delivery
>can be transactional or not (in case of transactional delivery, message is
>removed from queue only when message listener successfully finishes
>processing).
>
>So, till now events are like other messages in the J2EE environment where
>messages are posted to a topic (multicast delivery).
>
>

Different applications have different requirements. I tried to design
the event mechanism to work with a reasonably wide variety of
applications type, but the way events are used will differ from
application to application. When discussion events it's useful to
consider a number of scenarios, but it's also inportant to avoid mixing
them because the solutions will differ.

A problem with a pure message system is that a program not running
doesn't get messages. Duh, you say, but if the application is trying to
track database state or implement tasks that must be performed from
database updates, a log is critical. An example of this type of
application is one that needs to send out email notifications of
resulting from a database update. As you noted, this can't be done in a
UDF because you can't rollback an SMTP server. Using a message based
system doesn't work because a program not running doesn't get messages.
The rational (probably only) design for this type of system is for the
mailer to wake up, process any work queued for it, then wait on a wakeup
event. In this case, the log table is unavoidable.

Other types of application try to track the current state of a small
subset of data of interest to a user. These necessarily query the
database to get initial values. The most efficient implementation that
waits on all events associated with a datum of interest for a change.
This type of application doesn't need any sort of persistent log, and
probably could be implemented as a message service. It does, however,
require threads, and when I invented the event mechanism, threads didn't
exist. Firebird 2, as you are aware, does not require threads, so a
messaging system would be problem. Vulcan does require threads, so
maybe thought should be given to a messaging facility.

>
>
>>Futhermore, due to network latency and transaction atomicity, any
>>database state other than "something happened" is necessarily stale by
>>the time an event can be delivered and a new transaction started.
>>
>>
>
>Back to our example.
>
>What would be wrong with the design when the event contains ID of the
>team/user that was modified? Instead of reading the complete team/user
>change log application inspects exactly the team/user that was changed.
>Instead of "something happened" we send a "something happened to user 123"
>event.
>
>

If you knew that client applications would be interested in changes to
specific users, an update trigger could just post them. Events for
which there are no listeners get dropped on floor anyway, so the cost is
miniscule. There are two problems. One is that you can't know to wait
on things that don't yet exist, so insert operations are a problem.
The other is when you need to wait on more events that are feasible.
Wildcard events would probably address both problems (that's a topic for
the architecture list).

>Can you give an example where containing data in the event would be harmful,
>but storing the same data in log table would be the right solution?
>
>

A message containing notification that something has changed is
meaningless if it was deleted before the client program was able to read it.

The large question is where the server stores all of the messages that
clients have said they want but haven't asked for. A smaller question
is what happens when a transaction posts the same event over and over --
is it one event (in which case most of the database is dropped on the
floor) or many events that need to be posted, queued, requested, sent,
and received.

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.

>
>
>So, seeing your reply, I wonder, what's wrong with the design where data
>needed for information processing are send within the event itself instead
>of writing them into the table in the database?
>
>

It depends on what the application needs to. Again, describe the
application requirements and lets look at potential solutions.

>I will think about this issue more, since I'm not yet convinced that there
>should be only "something happened" events in the system, while you seems
>to know that for sure. But I would be grateful for any example that would
>help my understanding.
>
>
>
>

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.


--

Jim Starkey
Netfrastructure, Inc.
978 526-1376