Subject | Re: [firebird-support] Re: Event progamming, application do not stop |
---|---|
Author | Helen Borrie |
Post date | 2006-03-11T06:55:18Z |
At 05:01 PM 11/03/2006, you wrote:
It should have been written as "the interface part of the application
is put to sleep until..."
What it also leaves you to work out for yourself is that an
application logically cannot wait for a synchronous event that it
initiates for itself (the archetypal chicken-and-egg situation!).
Consider it:
1) Set up the EPB
2) Register interest with isc_wait_for_event (or exec sql event wait)
But now the interface is "sleeping", so you cannot make any more
function calls until the event returns. But the event will never
return because you can't make any calls to execute the stored
procedure or trigger in which you have planned for the event to occur.
If you want your application to receive notifications for its own
events, then of course you must use asynchronous events.
While there are some application scenarios where an application might
want to receive notifications for its own events, in most cases it is
not wanted. The application knows what it asked the server to
do. The application is responsible for starting and committing the
work that it requests. It does not need an event to inform it that
the server did what it was asked to do. Transactions are
atomic, meaning that they either do everything or they do none of
it. Events tell applications about things that they would not
otherwise know about.
./heLen
>Helen Borrie ,Hey, I didn't write the Borland documentation! :-)
>
>Thank you.
>
>
>Here is from borland:
>....
>As soon as the application uses the API isc_wait_for_event() or ESQL
>statement EXEC SQL EVENT WAIT, the application is put to sleep until
>the event is posted.
>...
>
>But my application can't be put to sleep at all .
It should have been written as "the interface part of the application
is put to sleep until..."
What it also leaves you to work out for yourself is that an
application logically cannot wait for a synchronous event that it
initiates for itself (the archetypal chicken-and-egg situation!).
Consider it:
1) Set up the EPB
2) Register interest with isc_wait_for_event (or exec sql event wait)
But now the interface is "sleeping", so you cannot make any more
function calls until the event returns. But the event will never
return because you can't make any calls to execute the stored
procedure or trigger in which you have planned for the event to occur.
If you want your application to receive notifications for its own
events, then of course you must use asynchronous events.
While there are some application scenarios where an application might
want to receive notifications for its own events, in most cases it is
not wanted. The application knows what it asked the server to
do. The application is responsible for starting and committing the
work that it requests. It does not need an event to inform it that
the server did what it was asked to do. Transactions are
atomic, meaning that they either do everything or they do none of
it. Events tell applications about things that they would not
otherwise know about.
./heLen