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.
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.
Related
I'm meeting a problem regarding session-state blocking in ASP.NET web page.
Normally, web-api projects don't have session state. However, as we develop from a legacy projects, web-api 2 module is injected to the old web-form project, and we proceed from there. However, now we detect 2 problems:
The AJAX requests always queue and execute one-by-one. It beats
the purpose of concurrent processing
For long-processing requests,
the user cannot move on another page, even if he/she doesn't need to
know the request result.
The culprit for (1) and (2) is session state blocking. We save authentication information into session state for the web-form projects; and then reuse them on the Web-API controllers. However, as any requests requiring the session, then they execute one-by-one, and for long requests, new request cannot come in even if the user already leave that page (the session is still blocked)
I have checked several answers from related issues, and it seems I'm not alone:
This question informs about the situation clearly, however didn't provide a clear solution (for Web-API case)
This question also give good advises about using Read-only session which does not block concurrency. However, we still not find out how to do with WebAPI controllers inside Web-form project.
According to MVC documents, we can disable session state by adding attribute [System.Web.Mvc.SessionState(System.Web.SessionState.SessionStateBehavior.ReadOnly)] on controllers' level. However it didn't work (as expected, because we have here Web-API controllers). Unfortunately, I didn't find similar attributes/any mechanism for web-api controllers.
I also check: in PHP case, they have the same issue, yet they can release the session lock early if they want to.
Therefore I'm wondering:
Is there a way to disable session for certain Web-API actions/controllers?
Is there a way to release the lock on session early, when we don't need it any more?
Dot Net serializes session state by default. You can decorate your class with a session modifier so that it can be accessed asynchronously without session state.
This works in cases where the client is java or jquery and they are polling your controller. The controller will release later than sooner. To make it more predictable place this specified on your class:
[SessionState(SessionStateBehavior.ReadOnly)]
function Do()
{
}
I am working on a web application which provide some services for its users who has accounts to log on to the web application. as you already probably know, it is possible to programmatically log in to web sites by providing username and password and sometime a catcha code. As I know it is possible to simulate the request programmatically. for example in c# we can make a request and fill all request headers such as User-Agent, Referer, .. and send it to the server in order to log in.
However, my question is how can I prevent users from logging in into web application via something other than browsers?
Thanks.
You can't. Timing, CAPTCHA and honeypot fields and using Javascript are common ways to prevent most robots, but someone dedicated to specifically targeting your site will find a way to simulate a genuine user.
All you can do it raise the barrier as high as you are able, and as high as is acceptable for your users. Security is always a trade-off against convenience.
There are ways you can raise the barrier, but each method's application varies across applications. For example, you could sniff the user agent and check it against a list and reject anything that isn't defined as a browser on your list. That kind of thing works for me in an internal situation where we have specific policies and controls over the browsers employees can use. For a web application however it would likely fail as the list would need to be managed, and people in the outside world probably know how to spoof their user agent anyway.
So it all depends. You need to consider the vectors around where your threats are coming from and guard against those threats as best you can rather than trying a blanket approach.
I am writing an MVC webAPI that will be used to return values that will be bound to dropdown boxes or used as type-ahead textbox results on a website, and I want to cache values in memory so that I do not need to perform database requests every time the API is hit.
I am going to use the MemoryCache class and I know I can populate the cache when the first request comes in but I don't want the first request to the API to be slower than others. My question is: Is there a way for me to automatically populate the cache when the WebAPI first starts? I see there is an "App_Start" folder, maybe I just throw something in here?
After the initial population, I will probably run an hourly/daily request to update the cache as required.
MemoryCache:
http://msdn.microsoft.com/en-us/library/system.runtime.caching.memorycache.aspx
UDPATE
Ela's answer below did the trick, basically I just needed to look at the abilities of Global.asax.
Thanks for the quick help here, this has spun up a separate question for me about the pros/cons of different caching types.
Pros/Cons of different ASP.NET Caching Options
You can use the global.asax appplication start method to initialize resources.
Resources which will be used application wide basically.
The following link should help you to find more information:
http://www.asp.net/web-forms/tutorials/data-access/caching-data/caching-data-at-application-startup-cs
Hint:
If you use in process caching (which is usually the case if you cache something within the web context / thread), keep in mind that your web application is controlled by IIS.
The standard IIS configuration will shut down your web application after 20 minutes if no user requests have to be served.
This means, that any resources you have in memory, will be freed.
After this happens, the next time a user accesses your web application, the global asax, application start will be excecuted again, because IIS reinitializes your web application.
If you want to prevent this behaviour, you either configure the application pool idle timeout to not time out after 20minutes. Or you use a different cache strategy (persistent cache, distributed cache...).
To configure IIS for this, here you can find more information:
http://brad.kingsleyblog.com/IIS7-Application-Pool-Idle-Time-out-Settings/
I have a web application with private/protected methods or private/protected variables
First I would like to know when a web-server has a connection established already for a certain web application and then receives a new connection does it run a new instance of the web application for this new connection and thus re-initializing all the variables in that web application just like on a computer?
I have goggled the Internet and I am terribly confused!
Second I am using the visual studio development server and I have learned that it doesn't accept connections from other computers, I have gotten around this by using a port forwarding software. So the question is, By doing this does VS2010 web-server see each different requests as a new request or same request since am forwarding them from an app on the local computer?
Finally if I have a web application open on one browser and then decide to open it on another browser and keep the current browser open is this treated as a new request or a post-back?
The app domain is constant (can be recycled) and is created only on the first request (also can be set before that).
That is to say all the static variables are initialized only once
but all the not static classes on which your request depends are initialized on every request.
So basically all your pages in normal asp.net and all the controllers in asp.net MVC are initialized on every request.
read more about it here http://www.codeproject.com/Articles/73728/ASP-NET-Application-and-Page-Life-Cycle
*note - the image has been take from the article referred above
Its a little more complicated than that. The process is optimised for mutiple connections and is stateless, however cashing can be used to imporve scalabilty: That which does not need to be reprocessed can simply be reused: http://www.dotnetfunda.com/articles/article821-beginners-guide-how-iis-process-aspnet-request.aspx is a good place to start understanding what can go on http://msdn.microsoft.com/en-us/library/bb470252%28v=vs.100%29.aspx is a somewhat dryer ms version "iis asp page life cycle" is a good google
The web application instance handles many many requests. And shared state (cache etc) is used very effectively across those requests, whether for a single session or multiple concurrent sessions.
When a request is made, the request object (and any "page" / "controller" object) is created for that request. The state of this object is fresh, but systems like "session state", "view state", cookies, and request values can be used to repopulate it - sometimes largely automated.
A single user making separate requests is not a post-back. They are separate sessions, but even a single session that opens the same page twice (tabs, etc) is not a post-back. It mainly depends on the http verb and other evidences to determine a post-back.
You've got to read this great article: https://lowleveldesign.org/2011/07/20/global-asax-in-asp-net/ for your question. Though it's a little late, it may help others out.
I'm writing a basic RESTful service, and decided I'd use ASP.NET MVC 3 for the task. My application is going to be responsible for maintaining a persistent connection to a server per user (for now). I had assumed that Application_Start is the place to register static/shared state (like persistent connections), but after reading the documentation for Unity.MVC3, it appears that each request/response cycle will trigger the creation of services (by calling Application_Start).
The documentation I refer to says:
On every request, one UpperCaseService, one LowerCaseService and one ExampleContext are instantiated by DependencyResolver via Unity. At the end of the request, the ExampleContext is automatically disposed
After reading other documentation, and from what I already assumed, Application_Start would be called per AppDomain spawned (again assumed that this would be in the vicinity of how many cores there are on the server).
So, what would be an effective way of maintaining a set of persistent connections to a server, that survive the request/response phase, and if possible, are shared between all AppDomains that the IIS server has created?
It might help to mention that this web service is only going to be consumed by another web site. It is essentially an Authentication Proxy server, however, in the future, it is going to do a lot more. Therefore, I can't just cache the response, as future requests will be required, and reauthenticating is not an option.
If you want to survive AppDomain restarts and share state between multiple ASP.NET applications you will have to go out of the IIS process and store this in a central location that is accessible from all applications. A database is a good candidate.