I am enjoying these Events and Messaging discussions.

I hope that we do not go the route of a mechanism
to be used for:

a) Automatic Replication
b) Automatic server data push to clients for data set
sychronization.

I've seen both attempted with Events and they were
nasty network intensive solutions that didn't scale.

Markus




Doug Chamberlin wrote:

>
> At 5/18/00 02:29 PM (Thursday), Jim Starkey wrote:
> >At 10:58 AM 5/18/00 -0400, Leyne, Sean wrote:
> > >Although at first glance events seem to be a useful
> > >feature, I have yet to be able to use them, they do not provide a
> > >meaningful context in the message. This requires a very time consuming
> > >to determine the context, the "cost" of which far outweighs the value of
> > >the message.
> >
> >Could you expand on this a bit? What did you want, how did you
> >try to do it, and what didn't work as you expected. I don't mean
> >this as a challenge, but to understand whether the existing event
> >mechanism is insufficient or just overly obscure.
>
> I'm sure Sean will respond, but I'd also like to so that I can learn how
> Jim envisions events being used. Mind you I have not yet used events
> because they did not seem to provide enough of a solution for any of my
> needs. Here is my generic description of the application developer's
> problem which might be solved via use of events:
>
> Let's say I have an application which lists a subset of records from a
> table in a visible window. The record set is obtained via a query with a
> WHERE clause. That application would like to know when any of those records
> are updated in the database so that it can update its window. If any of the
> records has been updated, the application would ideally like to re-issue
> the same query which populated the window.
>
> To accomplish this, you can code an update trigger of the table to signal
> an event such as TABLE_XYZ_UPDATE. When the application receives the event
> signal it now knows the table was updated but it does not know if the
> update was to one of the records it is currently displaying.
>
> Now the application could just re-issue its query for any such
> TABLE_XYZ_UPDATE event. However, it might end up doing a lot of unnecessary
> work if updates were all being done to another subset of the table. The
> application could also issue a new query to count how many of its current
> records have been updated recently (using some additional mechanism such as
> a timestamp field in the table).
>
> Both of those strategies involve extra work on the part of the application
> which quite likely to be unproductive some of the time.
>
> What I would like to see is the primary key value of the record being
> updated sent along with the event ID so that the application would know
> immediately if the update was relevant. No additional queries needed. No
> network bandwidth wasted. No guessing.
>
> ------------------------------------------------------------------------
> IT Professionals: Match your unique skills with the best IT projects at
> http://click.egroups.com/1/3381/4/_/830676/_/958676338/
> ------------------------------------------------------------------------
>
> To unsubscribe from this group, send an email to:
> IB-Architect-unsubscribe@onelist.com