Roman Rokytskyy wrote:

>>Roman, that's silly. A program that what wants notification of a stock
>>change doesn't wait on a generic event like "stock changed" but
>>something specific like "ibm". Other applications may indeed want
>>generic events, but they're backed up with log or "to do" tables.
>>
>>
>
>Ok, let's assume following situation:
>
>We have an application where the teams and users are cached. For the
>application this is a read-only cache, the application itself does not need
>to change the team membership. However, for correct functioning application
>must have the most up-to-date information about the user-team relationships.
>
>Which event in this case you want to post when user changes its team without
>sending user and/or team id so that cache does not poll the complete
>user/team table but only the changes?
>
>

table team_change_log(posted timestamp, team_id int, player_id int,
change_type int)

>That's your point of view, though there are vast amount of applications
>based on message passing. Whether Firebird events are equal to the messages
>used in stock trading systems, that's another question. Personall I think
>they do.
>
>

We've had this discussion about a million times. It always terminates
with "oh, I didn't think of that", but it's usually an informative,
educational sort of discussion. Shall we begin?

Starting point: Events must be robost and reliable, meaning specifically
that event notifications must be delivered, even if they occur at
inconvenient points such as notification or processing of the prior
event of the same name. 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. Many things could have happened in that time
including, potentially, intervening transactions that may mask or
invalidate data associated with an event.

>
>
>>Events. They are only alternative to polling the database.
>>
>>
>
>The caching in middle-tier helps if all changes go through that middle-tier.
>
>

We call that middle tier the database, which exists to manage data and
transaction consistency. I don't believe this can be done in a
different tier, and that we're better off looking at the real problem
rather than trying to make a bad workaround (a middle tier) less bad.
We should be looking for solutions to obviate the need for a middle
tier, not fix it.


[Non-text portions of this message have been removed]