I have tested this and it seems like even if the page unloads, the async action completes regardless if the tab is closed or if the tab navigates to a new url. The server it's calling to however is pretty snappy.
What is the process behind the scenes when it comes to async processes running and tabs being closed - at which point will the browser just call it quits on an async process that the page has started?
You cannot rely on the behavior of async calls from within onbeforeunload and onunload between servers.
We had an app that ran with an Apache server- Windows on our dev environment, and Unix on the release. It turns out that when the server was configured to handle requests in threads- default for our Windows/dev boxes- the Ajax would always complete; when it was configured to handle requests in processes- default for our Unix/prod environment, it would always cancel!
What happens is that the Ajax request fires, and then the browser unloads the page, which closes the connection for the Ajax reply. We set up a test where the Ajax call would execute a 4-second "sleep" on the server to avoid any timing issue. It looked like with a threaded back-end, Apache did not notice the client closing the connection until after it returned from the "sleep", whereas with the child-process backend, it aborted the Ajax call immediately.
The answer is to use synchronous requests in your on[before]unload event handler. That will keep the page open until the request completes. That does mean an additional delay when the page switches/reloads/goes back...
...and also you have no guarantee that the next page will see the results of that request- it seems that some browsers will GET the next page before firing the onunload event! But that's a topic for another question.