paulchwd

I know that Apache Tomcat Servlet Container (web server) for Java takes care of threads for the programmer... by any chance is ASP.Net the same....

lectricpharaoh

ASP.NET is a framework, not a server. That said, the server should be managing threads in the sense that it will distribute requests across a number of threads. It's not to say that it creates a single thread per request- in fact, it most likely doesn't- but rather that it has a pool of threads, and handles requests on one of the idle ones. This technique avoids the constant creation and destruction of threads (which incurs a fair bit of overhead, especially on busy servers).

__________________
And once again, Probability proves itself willing to sneak into a back alley and service Drama as would a copper-piece harlot.
- Vaarsuvius, Order of the Stick

paulchwd

thnx for the reply...I meant to say can IIS do this....

so each request is handled in a separate thread ..one of the unused ones in the pool... and thus my code will be syncronized?

lectricpharaoh

Synchronized with what? I'm not sure what you're getting at, here.

HTTP is a stateless protocol. When the user requests a resource, such as a web page, the server sends it to the client. If the resource consists of dynamically-generated content, the server generates the content, and sends it over. Multiple simultaneous requests can be handled, within the limits of the hardware; it doesn't matter if these come from the same client, or different ones. A single web page will often consist of multiple requests, the first for the page itself, and the rest for images and other items within the page. What makes HTTP stateless is that each request is a separate transaction; the browser opens a socket to the server, requests a resource, the server responds (this response is generally either the resource or an error, such as a 404), and then the socket is closed. Any appearance of a single 'session' is created by the use of cookies and/or form fields (usually hidden ones).

With ASP.NET, you're responding to user-generated events. Basically, what is happening on the client side is that when the user does certain things (such as clicking a button), client scripts (generated by ASP.NET as part of the content generation from your .aspx, .ascx, .vb, and .cs files) generate a request that is sent to the server (except for some cases such as rollovers, etc). Threading isn't really an issue here, as most of your requests should be resolved in a timely fashion. Any lengthy processing means a delay before the content is generated, which means that the server won't even start sending it to the client, who will probably say 'fuck it' and navigate away from the page (perhaps after clicking 'refresh' a few times). It's not like Windows forms programming, where you can run the UI on one thread and a lengthy background task on another, whilst updating a progress bar or something (well you sort of can, but probably not in the way you might think).

__________________
And once again, Probability proves itself willing to sneak into a back alley and service Drama as would a copper-piece harlot.
- Vaarsuvius, Order of the Stick