At 07:41 PM 5/6/01 +0400, Dmitry Yemanov wrote:

>
>Just an example. As far as I remember, someone asked a question in one
>forum: how can I monitor in my grid the changes made by other users who work
>with the same table? A decision with a trigger that post a single event was
>proposed. But he wasn't satisfied, because he didn't want to refresh the
>whole grid. Then someone else (Helen, weren't it you?) advised to post from
>the trigger an event that contains PK of the modified record and on the
>client side listen for all events that match rows displayed on the screen.
>As for me, it is terrible approach, but it looks to be the best solution
>that was available until now. But with the introduction of wildcarding it
>becomes quite simple to react with the given resolution (row/table/database
>level) to any things that happen within database, because of (for example):
>post_event 'EMPLOYEE' || '_INSERT_' || CAST(new.ID AS VARCHAR(10)), which
>can be easily parsed on the client side.
>

Very clever. A nice extension.

If the wildcard string is entered into the event table is an
explicit event with its own event count, it looks good me
with a caveat or two on resource usage.

In the original architecture (and, I believe, the current
implementation) the event table is in System V shared memory.
On most Unix systems, System V shared memory is implemented
in non-paged (i.e. real) memory. To minimize the amount of
memory required, the event manager was designed to track
only events for which an attached process has declared an
interest. Tracking only "interesting" events is no big deal.
However, with you wildcarding mechanism, any event that matches
an active wildcard must be tracked. Depending on the the
application, this might increased to number of events tracked
from a typical couple of dozen to hundreds of thousands,
millions, or more. If an application needs the functionality,
this may well be worth the cost. But the ramification on
configuration and limits of shared memory size should be
carefully explored.

On the other hand, the super-server has no need for a shared
memory based event manager. Ditching the shared memory mechanism
would also eliminate the need to ackward region relative addresses
necessary to keep the event manager data structure position
independent. A faster, cheaper, more flexible event manager
should be a dividend of the super server architecture.

I rather like the wildcard scheme that preserves a valid
event count but also provides the detailed events that triggered
the wildcard event.

Nice piece of work, Dmitry.




Jim Starkey