Subject Re: [Firebird-Java] Responding to Firebird events
Author Roman Rokytskyy
> 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?

> Passing data associated with events vastly increases the amount of event
> state maintained by the server, the amount of network traffic,
> complicates application design, and ultimately doesn't gain you anything.

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.

> Roman, Roman, Roman! I am not a complete fool. Events are under
> transaction control and posted to the event manager *after* a
> transaction commits. They can't work any other way, actually, since the
> data that reflects the event isn't available to other transactions until
> the posting transaction completes.

I am talking about the UDF, not events. UDF is out of transaction control,
though it can be use to notify about the changes on the record level. Cache
receives the notification and marks an entity as dirty. On next access it
will re-read it.

> Events. They are only alternative to polling the database.

The caching in middle-tier helps if all changes go through that middle-tier.
This is how entity beans work, this is how Hibernate cache works. Adding a
multicasting component allows to sync caches on different nodes (this is how
Tangosol Coherence, JBoss Cache works, and I suspect that WebLogic entity
bean cache in cluster works).