Subject | Re: [Firebird-Java] Responding to Firebird events |
---|---|
Author | Roman Rokytskyy |
Post date | 2005-05-29T12:16:03Z |
> Roman, that's silly. A program that what wants notification of a stockOk, let's assume following situation:
> 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.
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 eventThat's your point of view, though there are vast amount of applications
> state maintained by the server, the amount of network traffic,
> complicates application design, and ultimately doesn't gain you anything.
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 underI am talking about the UDF, not events. UDF is out of transaction control,
> 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.
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).
Roman