what is an asynchronous event?

[ALI-R]

Hi All,

When we say events are processed asynchronously in for instance Sharepoint
,what dose it mean?

Thanks for your help.
Ali

[ALI-R]

I somehow know what synch and asynch are.here might not be a good place to
ask this question and maybe I have to post it to sharepoint newsgroup but
**symantically** I have problem underestanding this parageraph:
"Events are processed asynchronously. As a result, a registered event
handler will only be notified about the document deletion after that
document has already been deleted from the SQL ServerT backend database."

Thanks

"John Timney (ASP.NET MVP)" <ti*****@despammed.com> wrote in message
news:uI****************@TK2MSFTNGP10.phx.gbl...

Synchronous means that two things happen with some type of
synchronization -- I.e. there's a well-defined relationship between the
times at which the two happen. Ie a radio'conversation - speak your words
and say over, then the next person speaks and says over.

Therefore Asynchronous means the opposite in that there's not really a
well-defined relationship between the times at which two things happen.
Like a telephone conversation - one person doesn't have to finish speaking
before the other speaks.
--
Regards
John Timney
ASP.NET MVP
Microsoft Regional Director

"ALI-R" <ne****@microsoft.com> wrote in message
news:ul**************@TK2MSFTNGP12.phx.gbl...

Hi All,

When we say events are processed asynchronously in for instance Sharepoint ,what dose it mean?

Thanks for your help.
Ali

[Bruce Wood]

I read this as saying that there is no synchronous way to delete a
document from SharePoint. You have no choice but to supply an event
handler that will be called after the document has been deleted. If you
want synchronous behaviour (delete-and-wait-for-completion) then you
have to code it yourself.

That's what I get out of it, anyway.

[John Timney \(ASP.NET MVP\)]

Sorry for posting with a messed up date - I have corrected this.

--
Regards

John Timney
ASP.NET MVP
Microsoft Regional Director

"John Timney (ASP.NET MVP)" <ti*****@despammed.com> wrote in message
news:uI****************@TK2MSFTNGP10.phx.gbl...

Synchronous means that two things happen with some type of
synchronization -- I.e. there's a well-defined relationship between the
times at which the two happen. Ie a radio'conversation - speak your words
and say over, then the next person speaks and says over.

Therefore Asynchronous means the opposite in that there's not really a
well-defined relationship between the times at which two things happen.
Like a telephone conversation - one person doesn't have to finish speaking
before the other speaks.
--
Regards
John Timney
ASP.NET MVP
Microsoft Regional Director

"ALI-R" <ne****@microsoft.com> wrote in message
news:ul**************@TK2MSFTNGP12.phx.gbl...

Hi All,

When we say events are processed asynchronously in for instance Sharepoint ,what dose it mean?

Thanks for your help.
Ali

[James Curran]

I'm guessing that the code in question is something like this
psuedo-code.

Fire Event "About to Delete File"
Delete file
Fire Event "File Deleted"

However, since the "Fire Event" method will only place the event in the
message queue, nothing will recieve either event until after the file has
been deleted. If the events were synchronous, then Fire Event would not
return until all listeners had received the event.
"ALI-R" <ne****@microsoft.com> wrote in message
news:uU**************@TK2MSFTNGP12.phx.gbl...

I somehow know what synch and asynch are.here might not be a good place to
ask this question and maybe I have to post it to sharepoint newsgroup but
**symantically** I have problem underestanding this parageraph:
"Events are processed asynchronously. As a result, a registered event
handler will only be notified about the document deletion after that
document has already been deleted from the SQL ServerT backend database."

[ALI-R]

So what I have underestood of what told me is that the process is like this
in **Asynchronous** approach:

1) User requests to delete the File
2) The file is deleted
3) Event handler gets notified about Deletion

So ,if we pretend that Events are process **Synchronously** the sequence
would be like this:

1) User requests to delete the File
2) Event handler gets notified about Deletion
3) The file is deleted.

Correct me if I'm wrong!!!thanks for yur help

Thasnks
Ali
"ALI-R" <ne****@microsoft.com> wrote in message
news:ul**************@TK2MSFTNGP12.phx.gbl...

Hi All,

When we say events are processed asynchronously in for instance Sharepoint
,what dose it mean?

Thanks for your help.
Ali

[ALI-R]

So what I have underestood of what told me is that the process is like this
in **Asynchronous** approach:

1) User requests to delete the File
2) The file is deleted
3) Event handler gets notified about Deletion

So ,if we pretend that Events are process **Synchronously** the sequence
would be like this:

1) User requests to delete the File
2) Event handler gets notified about Deletion
3) The file is deleted.

Correct me if I'm wrong please!!!thanks for your help

Thasnks
Ali

"James Curran" <ja*********@mvps.org> wrote in message
news:Oi**************@TK2MSFTNGP11.phx.gbl...

I'm guessing that the code in question is something like this
psuedo-code.

Fire Event "About to Delete File"
Delete file
Fire Event "File Deleted"

However, since the "Fire Event" method will only place the event in the
message queue, nothing will recieve either event until after the file has
been deleted. If the events were synchronous, then Fire Event would not
return until all listeners had received the event.
"ALI-R" <ne****@microsoft.com> wrote in message
news:uU**************@TK2MSFTNGP12.phx.gbl...

I somehow know what synch and asynch are.here might not be a good place to ask this question and maybe I have to post it to sharepoint newsgroup but **symantically** I have problem underestanding this parageraph:
"Events are processed asynchronously. As a result, a registered event
handler will only be notified about the document deletion after that
document has already been deleted from the SQL ServerT backend

database."

[Bruce Wood]

No, a synchronous invocation would look like this:

1) User requests to delete a file. User is left waiting.
2) File is deleted
3) Control is finally returned to user after file is deleted.

You have the idea of asynchrony correct:

1) User requests to delete a file; control is immediately returned to
user
2) File is deleted
3) User is notified that file is deleted.

Of course, in both of these scenarios, "user" can be seen as the real
user (synchrony is bad form in this case, leaving the user with an
unresponsive application while the file deletion is taking place), or
"user" can be seen as the program calling the deletion routine.

In synchronous invocation ,what is the role of event handler? where is the
event handler in this approach? you only talked about the use,my interest is
to know how event handler gets notified in synchronous invocation .

1) User requests to delete a file. User is left waiting.
2) File is deleted
3) Control is finally returned to user after file is deleted.
Thanks Bruce,
ALi-R

"Bruce Wood" <br*******@canada.com> wrote in message
news:11**********************@c13g2000cwb.googlegr oups.com... No, a synchronous invocation would look like this:

1) User requests to delete a file. User is left waiting.
2) File is deleted
3) Control is finally returned to user after file is deleted.

You have the idea of asynchrony correct:

1) User requests to delete a file; control is immediately returned to
user
2) File is deleted
3) User is notified that file is deleted.

Of course, in both of these scenarios, "user" can be seen as the real
user (synchrony is bad form in this case, leaving the user with an
unresponsive application while the file deletion is taking place), or
"user" can be seen as the program calling the deletion routine.

[Bruce Wood]

I don't know about the particular routines you're calling, but usually
a synchronous invocation does not involve event handlers at all: you
call a method, it waits until some operation completes, then it returns
to you.

Of course, there may be an asynchronous invocation going on under the
covers. Some "synchronous" method invocations are nothing more than
methods that send an event and don't return until the corresponding
reply event comes back. However, from the point of view of the caller,
a synchronous invocation doesn't need an event handler because you know
when the operation is done: when the method returns.

[ALI-R]

Thanks Bruce,Like always your answers are informative.

Ali-R
"Bruce Wood" <br*******@canada.com> wrote in message
news:11*********************@z14g2000cwz.googlegro ups.com...

I don't know about the particular routines you're calling, but usually
a synchronous invocation does not involve event handlers at all: you
call a method, it waits until some operation completes, then it returns
to you.

Of course, there may be an asynchronous invocation going on under the
covers. Some "synchronous" method invocations are nothing more than
methods that send an event and don't return until the corresponding
reply event comes back. However, from the point of view of the caller,
a synchronous invocation doesn't need an event handler because you know
when the operation is done: when the method returns.

[Bruce Wood]

Thanks. :)

One more thing: I just remembered an example of a synchronous operation
that accepts a delegate, which is easily confused with an event handler
(since handling events is a common use for a delegate).

If you look at Image.GetThumbnailImage(), you'll see that it accepts a
"callback delegate", even though it is a synchronous operation (that
is, it doesn't return to its caller until the thumbnail image is
complete).

Don't confuse this with an "event handler". GetThumbnailImage() calls
this delegate from time to time to see if the user wants to cancel the
operation. However, it's just a delegate. There are no events involved.
Same language construct, different purpose.

[ALI-R]

Bruse a quick question:

For innstance calling Update method from DataAdapter (According to your
explanation) must be classified as Synchronous invocation,right?
because the user is left waiting till he gets notified by the result of his
invoction.

Thanks
Ali-R
"Bruce Wood" <br*******@canada.com> wrote in message
news:11*********************@z14g2000cwz.googlegro ups.com...

Thanks. :)

One more thing: I just remembered an example of a synchronous operation
that accepts a delegate, which is easily confused with an event handler
(since handling events is a common use for a delegate).

If you look at Image.GetThumbnailImage(), you'll see that it accepts a
"callback delegate", even though it is a synchronous operation (that
is, it doesn't return to its caller until the thumbnail image is
complete).

Don't confuse this with an "event handler". GetThumbnailImage() calls
this delegate from time to time to see if the user wants to cancel the
operation. However, it's just a delegate. There are no events involved.
Same language construct, different purpose.

[Bruce Wood]

Yes. I've used it myself, and it's synchronous: the caller is left
waiting until the database is updated and the number of affected rows
is returned.

I haven't tried this myself, but if you wanted an asynchronous Update
(update the database while "I" (the calling method) continue to do
something else, and let me know when you're done), it looks to me as
though you have to "roll your own" asynchrony by spinning off another
thread and asking for notification when that other thread finishes its
work (the Update). That way you could continue what you were doing
while the other thread blocked on the Update operation. When the
Updated completed, the other thread would then send you an event (via
Invoke) to tell you that it was done, and terminate.

Your thread (the main thread) could then continue working while the
Update was happening, and either pay little attention to the resulting
event coming back, or, if the user asked to do something that logically
required the update to be complete, block at that point, waiting for
the Update to finish before moving on. (Asynchrony doesn't mean that
you can't _ever_ wait for the operation to complete before moving on;
it just means that you have the choice not to wait if you don't want
to. In a synchronous world, you have no choice: you have to wait.)

You might want to read at least part of Jon Skeet's article on threads:
http://www.yoda.arachsys.com/csharp/threads/