Subject Re: firebird events question
Author russellbelding
Hello Helen

--- In, Helen Borrie <helebor@t...>
> At 09:24 PM 17/09/2004 +0000, you wrote:
> >I wonder if it would be possible for the firebird developers to
> >modify the event listener regisration code so that a client
> >for events could register for events such as 'MY_EVENT*' and then
> >sent all events with names matching 'MY_EVENT*'?
> >
> >I think this capability would be benefical to both of us.
> >
> >For example: ...
> >
> >At present the server-side event notification is triggered by the
> >invocation of POST_EVENT 'ANYNAME'
> >There seems to be no possibility (please correct me anyone if I am
> >wrong) to send an addittional parameter with 'ANYNAME', such as
> >sending back a key for the record just inserted or updated. Inside
> >the trigger or procedure calling POST_EVENT the event name can
> >be "mangled" to produce "ANYNAME:1234567" but this changes the name
> >of the event and on the client side only a client who has
> >as a listener for an event named "ANYNAME:1234567" wil be notified.
> >
> >By contrast if a client could register as a listener for events
> >like 'ANYNAME*' then they would get notice of
> >event "ANYNAME:1234567", peel off the key value "1234567" and
> >the event 'ANYNAME' as they wish.
> >
> >So here is a simple case for expanding the event notification code
> >allow for registering for events named with wild card names.
> Isn't this the opposite of what you asked for? You said you wanted
> client to be able to *ignore* any events that had been fired by its
> process.

Using the wild card event scheme a client would get messages fom
events caused by themselves but would, by virtue of a code appended
detect the event was their event and do nothing. It is sufficient for
my needs that events identify the client causing the event.
> >Is there a way to achieve this functionality with using the
existing scheme?
> You can already send an event that includes the user name (listen
> from server), e.g.
> ...
> declare ThisEvent varchar(15) = '1234'||CURRENT_USER;
> ...
> ...
> POST_EVENT(ThisEvent) ;

This won't satisfy my requiremnt for a client to listen, for example,
for all insertions to a table as I cannot assume a client will know
who the CURRENT_USERS are at any one time, nor even how many users
there are.

> (provided your system has very short user names! Event names are
> to 15 bytes )

There is an addition for Chapter VII of "Firebird Book"; but the 15
char length of event anmes is explicit on page 684.

> Since the client application knows its username, you already have
> capability to have a client listen for its own events. But that's
no good
> for the generic purpose of events, which is to have everyone listen
for an
> event. If only the instigating client knows the name of the event,
none of
> the others knows what to listen for. If you add your original
requirement -
> to have the client ignore its own events - then this user-specific
> has nowhere to go.

Ah yes you saw this too.

> Whether it would be a Good Thing to re-architect events to make
them a
> full-blown messaging subsystem isn't a subject for the support list
but one
> you might care to raise on firebird-architect, if you have strong
> about it.

Perhaps I'll try to make a case for it there as a hopefully simple
extension to Firebird code.

> Since (I think!) you are using IBO, why don't you just use
DMLCaching? If
> I've understood your requirements, it already implements exactly
what you
> want: clients listening for DML commits and optionally ignoring
their own.

Yes I am using IBO, I do not know of DML Caching so I'll look it up.
By reading the IBO help manual, and I have trouble understanding it,
DML Caching can sync changes made in datasets using a common
transaction. So this won't serve to inform one instance of my program
if another instance changed something in a table as their
transactions will not be common.



> ./heLen