Subject | Re: [firebird-support] Performance of events |
---|---|
Author | Daniel Albuschat |
Post date | 2009-12-15T14:26:22Z |
2009/12/15 John vd Waeter <john@...>
I use events as much as I can, it's a great thing to be informed by the
couldn't solve:
How are entries from this event-list removed? I see no way to recognized
that nobody is interested in this event anymore.
Additionally, it increases round-trips, because the client has to query the
server for more information before processing the event. On the other hand,
this does not feel so bad when you look at what you can gain.
Daniel
--
eat(this); // delicious suicide
[Non-text portions of this message have been removed]
>[snip]
> > On the other hand, I have the feeling that events are a feature that
> don't
> > receive much love from the developers.
> >
> > Perhaps some dev might be able to tell us more.
> >
> > Daniel
>
I use events as much as I can, it's a great thing to be informed by the
> server that something interesting has happened. But inside the trigger II came up with that idea, too, but there's one fundamental problem I
> also write an event-table with some info about the cause of the event
> and concerning record-id's. This eventtable has a generated id of its
> own, and my clients allways check periodically if no events where missed
> (by comparing the last read ID).
>
couldn't solve:
How are entries from this event-list removed? I see no way to recognized
that nobody is interested in this event anymore.
Additionally, it increases round-trips, because the client has to query the
server for more information before processing the event. On the other hand,
this does not feel so bad when you look at what you can gain.
> Further they react on events with aI see, that's probably a good idea.
> random delay to prevent huge pileups at port 3050...
>
Daniel
--
eat(this); // delicious suicide
[Non-text portions of this message have been removed]