Reputation: 892
I am working on a ASP.NET MVC project that should be implement a multi-threading functionality. In fact, in this application, a user can navigate from a page to an other, so he can change the action of his current controller. My question is, Is there a way in ASP.NET MVC that can guarantee that the action is running in background, even though the user has switched the action. It means that even when he returns to the View after he navigates, he can get what he has launched in his current session (knowing that it may take a bit of time in order to do it).I know that it is contradictory with the MVC pattern, but this application should be a server side application.
I did some research and they say that a thread pool and asychronous controllers (http://msdn.microsoft.com/en-us/library/ee728598%28v=vs.100%29.aspx#performing_multiple_operations_in_parallel) may be a solution to this problem. I will be glad to hear any other suggestions to help me implement this project in the right way.
Upvotes: 1
Views: 1466
Reputation: 1016
I think you should re-visit the premise that this should be implementing a parallel pattern.
For this to work the way I think you want it to, you will need a shared cache keyed by session id's. Your asynchronous tasks will be storing their results there. You will need some middleware that is initialized when the app initializes, this middleware would consist of a managed thread pool and a buffered queue of tasks. Your UI threads/web server threads would queue a task for the middleware to handle and dump the results in the shared cache which you would then check for results on subsequent web requests from that client. That's a lot of work. Especially if your client and server side applications are already intimately tied together as they usually are in ASP.NET.
Or, you could move the application away from ASP.NET and implement the server side application as a REST API in C# that your client application, written in Javascript, would hit using ajax requests. You build the client app as a single page app in some js MVC framework. This will allow the user to the client app in a seamless experience as calls to the server are non-blocking unless the client app wants them to be. Then there's really no need for the asynchronous patterns you mentioned above, which, honestly are not going to give you any sort of performance gains and it's not going to scale well.
Upvotes: 1