I have an asynchronous controller,
I know the action will work asynchronously (no other action wait for that) and returns after completion of the task.
So my question is how it is deferent from making an asynchronous Ajax request to an action.
I think both are same in result.
An async request from javascript is not the same as an async task on the server.
An async task from javascript is still processed synchronously on the server, and as such, you may encounter thread pool starvation on large applications.
Having an async request that is processed asynchronously on the server is different, it frees up the IIS thread to immediately process other requests while that request, either from javascript or a full post/get is processed in the background.
some reading may help
http://msdn.microsoft.com/en-us/library/ee728598(v=vs.98).aspx#processing_asynchronous_requests
Related
I know that Express allows to execute asynchronous functions in the routes and in the middlewares, but is this correct? I read the documentation and it specifies that NO ROUTES OR ASYNCHRONOUS MIDDLEWARES SHOULD BE ASSIGNED, today, currently, does Express support asynchronous functions? Does it block the execution process? o Currently asynchronous functions DO NOT BLOCK THE EXECUTION PROCESS?,
For example, if I place in an asynchronous route, and if requests are made in that route at the same time, are they resolved in parallel?, that is:
Or when assigning asynchronous routes, will these requests be resolved one after the other ?, that is:
This is what I mean by "blocking the execution process", because if one fails, are the other requests pending? or Am I misunderstanding?
I hope you can help me.
You can use async functions just fine with Express, but whether or not they block has nothing to do with whether they are async, but everything to do with what the code in the function does. If it starts an asynchronous operation and then returns, then it won't block. But, if it executes a bunch of time consuming synchronous code before it returns, that will block.
If getDBInfo() is asynchronous and returns a promise that resolves when it completes, then your examples will have the three database operations in flight at the same time. Whether or not they actually run truly in parallel depends entirely upon your database implementation, but the code you show here allows them to run in parallel if the database implements that.
The single thread of Javascript execution will run the first call to getDBInfo(), that DB request will be started and will immediately return a promise. Then, it will hit the await and it will suspend the execution of the containing function. That will allow the event loop to then start processing the second request and it will do the same. When it hits the await, it will suspend execution of the containing function and allow the event loop to process the third request will do likewise. Then, sometime later, one of the DB calls will complete (it could be any one of the three) which will resolve its promise which will unsuspend the function and it will send the response. Then, one after another the other two DB calls will finish and send their responses.
i can't understand why use Asynchronous and await when fetch data from server
A network request from a client to a server, possibly over a long distance and slow internet can take an eternity in CPU time scales.
If it weren't async, the UI would block until the request is completed.
With async execution the UI thread is free to update a progress bar or render other stuff while the framework or Operating System stack is busy on another thread to send and receive the request your code made.
Most other calls that reach out to the Operating System for files or other resources are async for the same reason, while not all of them are as slow as requests to a remote server, but often you can't know in advance if it will be fast enough to not hurt your frame rate and cause visible disruption or janks in the UI.
await is used to make code after that statement starting with wait is executed only when the async request is completed. async / await is used to make async code look more like sync code to make it easier to write and reason about.
Async helps a lot with scalability and responsiveness.
Using synchronous request blocks the client until a response has been received. As you increase concurrent users you basically have a thread per user. This can create a lot of idle time, and wasted computation. One request gets one response in the order received.
Using asynchronous requests allows the client to receive requests/send responses in any random order of execution, as they are able to be received/sent. This lets your threads work smarter.
Here's a pretty simple and solid resource from Mozilla:
https://developer.mozilla.org/en-US/docs/Web/API/XMLHttpRequest/Synchronous_and_Asynchronous_Requests#Asynchronous_request
I am using sendAsynchronous request to receive data from multiple request at same time. It works great, i am able to load all the data. Even it is faster. But i want to cancel my request if the user cancels the request. so i have created a NSThread and using that thread i have created asynchronous request. When user clicks cancel button i just cancelled the thread.
But even after cancelling the thread the data is still getting loaded. So i want to stop those requests completely from loading data.
Even i used this,
[NSObject cancelPreviousPerformRequestsWithTarget:(id) selector:(selector) object:(id)]
but it doesn't work. Any help or suggestion will be appreciated.
Thanks in advance.
According to the documentation the NSUrlConnection class has it's own cancel method.
Note: Why are you using sendAsynchronousRequest in a own thread? The completion-handler will be executed when the request returns. While the request tries to reach the server and get an answer the main-thread shouldn't be blocked. I suggest to use either a synchronous request in a background thread or an asynchronous request in your main thread.
Also be aware, that your thread doesn't terminate just by calling [NSThread cancel]
Is it best to send a synchronous or an asynchronous request?
I'm sending a request to a server, asking for a list of files, which I would like the user to choose from.
Synchronous request does stop the application from any user action until it completes, because it runs in the main thread.
Asynchronous does not as it runs in other thread.
You should always use asynchronous requests as they do not block the thread they are called from. Instead they will call your delegate methods when the connection fails or succeeds. If you need to prevent the user from doing anything while the connection is running, use a HUD class like MBProgressHUD (check github).
You'd want to use asynchronous calls when you're calling from the Main Thread. Otherwise, the whole user interface will become unresponsive (i.e: freeze) until the server responds. (The user interface in maintained by the main thread).
You'd want to use synchronous calls when you're calling from another thread and you want it to wait until it has the response before continuing. If you've manually created a thread, calling asynchronous from this new thread would create a third thread.
Asynchronous means the "calling body" won't wait until the task is done.
I have a web request that can take 30-90 seconds to complete in some cases(most of the time it completed in 2-3). Currently, the software looks like it has hung if the request takes this long.
I was thinking that I could use background worker to process the webrequest in a separate thread. However, The software must wait on the request to process before continuing. I know how to setup the background worker. What I am unsure about is how to handle waiting on the request to process.
Do I need to create a timer to check for the results until the request times out or is processed?
I wouldn't use a timer. Rather, when the web request completes on the worker thread, use a call to the Invoke method on a control in the UI to update the UI with the result (or send some sort of notification).