Subject | Re: [firebird-support] Newbee to events - how to know which record changed |
---|---|
Author | Milan Babuskov |
Post date | 2009-03-12T15:42:01Z |
Maya Opperman wrote:
background and "wake up" when event fires. Since they run all the time,
they can keep the state and know where they "left off". For example,
instead of querying all the tasks completed today, each time you get the
event and process it, save CUREENT_TIMESTAMP in some local variable of
the application. Next time event fires, just query
WHERE update_time > :last_time
to get records that were updated since. This is one type of application.
Another type is when you have for example two programs doing two
different tasks but sharing the same data. For example, I have a POS
application and another application that prints bills on printer. POS
application creates the record and waits for 'printed' event to see if
the other application did the job. On the other end, the printer
application waits for 'new_print_job' event and when if receives it, it
reads the print_queue table from the database, does the actual printing
and flags the record in database (during which the 'printed' event is
sent). POS application sees the 'printed' event and checks the record it
inserted just a while ago to see if it is done. Since speed is essential
here, before I used events, I used to poll from both applications at
300ms interval and with many users connected it caused slowdown. With
events, system load is really small and applications react immediately.
--
Milan Babuskov
http://www.flamerobin.org
http://www.guacosoft.com
> My question is, how do I know what record triggered the event? Is thereNo. You need to query the tables in database.
> any way of passing additional data through to the application?
> If I do a query for all tasks completed todayApplications that listen to events are meant to run all the time in the
background and "wake up" when event fires. Since they run all the time,
they can keep the state and know where they "left off". For example,
instead of querying all the tasks completed today, each time you get the
event and process it, save CUREENT_TIMESTAMP in some local variable of
the application. Next time event fires, just query
WHERE update_time > :last_time
to get records that were updated since. This is one type of application.
Another type is when you have for example two programs doing two
different tasks but sharing the same data. For example, I have a POS
application and another application that prints bills on printer. POS
application creates the record and waits for 'printed' event to see if
the other application did the job. On the other end, the printer
application waits for 'new_print_job' event and when if receives it, it
reads the print_queue table from the database, does the actual printing
and flags the record in database (during which the 'printed' event is
sent). POS application sees the 'printed' event and checks the record it
inserted just a while ago to see if it is done. Since speed is essential
here, before I used events, I used to poll from both applications at
300ms interval and with many users connected it caused slowdown. With
events, system load is really small and applications react immediately.
> I presume I need to have some kind of an event logging table and insertYes, the main benefit from events is to prevent constant polling.
> the relevant information in there. In which case, I don't even need
> events at all anyway?? (OK, maybe just one event on my EventLog table
> every time a record is inserted to save me polling it periodically
--
Milan Babuskov
http://www.flamerobin.org
http://www.guacosoft.com