Subject | Re: [ib-support] About post_event |
---|---|
Author | Helen Borrie |
Post date | 2002-04-19T12:19:19Z |
At 10:54 AM 19-04-02 +0000, you wrote:
client. Its potential to add both network and client processing overhead
is obvious. So, in designing applications that use events, you need to
balance the benefit against the cost.
For example, IB Objects has the ability to something termed "DML
Caching". It is possible for each connected client to receive updates
every time something changes in the database, regardless of which
application is using it or how many users are connected. It is implemented
with events and triggers.
This has obvious benefits in a highly interactive production scenario,
where the "real-time" requirements have high priority and where updates
typically happen one-by-one. In a largely batched production environment,
with few inter-dependencies, it would be a pointless
waste. (Still...consider how useful it is in a process control
environment, regardless of the overhead it costs!) Everything between is
a matter of degree. As a general rule, one choose the tasks for which such
a thing would be useful, rather than just blindly implementing it
everywhere or rejecting it as "everything that uses resources
non-essentially is out".
Helen
All for Open and Open for All
Firebird Open SQL Database · http://firebirdsql.org ·
http://users.tpg.com.au/helebor/
_______________________________________________________
>Hi friends...As a qualitative comment, post_event is an interaction with a listening
>Can someone let me know if intensive use of post_event
>will degrade performance of FB or of the Network?
>i.e. i would use a post_event in a after update trigger
>of my tables, just to update some cache in my apps..
>This will be praticable?
client. Its potential to add both network and client processing overhead
is obvious. So, in designing applications that use events, you need to
balance the benefit against the cost.
For example, IB Objects has the ability to something termed "DML
Caching". It is possible for each connected client to receive updates
every time something changes in the database, regardless of which
application is using it or how many users are connected. It is implemented
with events and triggers.
This has obvious benefits in a highly interactive production scenario,
where the "real-time" requirements have high priority and where updates
typically happen one-by-one. In a largely batched production environment,
with few inter-dependencies, it would be a pointless
waste. (Still...consider how useful it is in a process control
environment, regardless of the overhead it costs!) Everything between is
a matter of degree. As a general rule, one choose the tasks for which such
a thing would be useful, rather than just blindly implementing it
everywhere or rejecting it as "everything that uses resources
non-essentially is out".
Helen
All for Open and Open for All
Firebird Open SQL Database · http://firebirdsql.org ·
http://users.tpg.com.au/helebor/
_______________________________________________________