Concurrency in web applications

Question

So recently there has been a lot of emphasis by almost all platform providers to provide new tools/language constructs for better concurrency. And that is also one of the re

Answer 1

To my understanding, the question arises from the complication of two different implications of the concept concurrency: the concurrent service of a web site to user requests (macro level) vs. the concurrent execution of two programs/processes/threads (micro level).

They use both the same word concurrent, yet the former is homogeneous, if we simply assume the server provides just one service, and there is no interaction/commonage between the macro-level services provided to different users. Even if the services to different users go to the data storage level and thus contend for IO resources, that's more of a problem of the micro-level: two queries/writes race against each other for common resources. As an abstraction the services provided to users are always homogeneous, therefore concurrency functionality/libraries provided by platforms (you mean Java, .Net, and etc. I guess) has nothing to do with web apps, but with only the micro operations far beneath them.

Answer 2

Yes, in high performance server and long running tasks

Check out Async controllers in ASP.Net MVC

Answer 3

The strict view of everything being synchronous and consistent is not scaling well enough. There is then a tendency to have more stuff asynchronous and to accept eventual consistency. This also reflects in the way languages and framework are designed.

Lots of inspiration is drawn from the functional area because it fits well with this mode of computation. Functional programming helps to reason about what to perform rather than how and when.

This actually complements the otherwise traditional mechanism to deal with concurrency.

I couldn’t find a lot of sample scenarios in which the recent concurrency platforms and libraries can be used in context of web apps. So I would like to know if they make a lot of sense in the web domain.

This depends on what you mean. You won’t necessary need to use low-level construction such as the one in java.util.concurrent. But asynchrony is supported better and better along the framework stacks. For instance, Servlet 3.0 introduces asynchronous web request to ease the development of AJAX applications. As a consequence, EJB 3.1 have asynchronous method invocation to integrate with the asynchronous web layer. At the bottom we have the low-level abstraction of function (or delegate, closure) which abstracts the computation itself, and the information necessary for the computation (its context). I guess the same is true for .NET.

Not related to traditional web application, but rather to the web as “the cloud,” functional programming helps with distributed computation across CPU and nodes. A well-known example is map/reduce and the likes, which aim at processing large set of data.

All that fits together, and we see a web application which stays responsive, while large set of data are processed asynchronously.

But no, you won't necessary need all that for a traditional web app!

Answer 4

Sure concurrency platforms make a lot of sense in web apps. Just look at SO (and the multi-tenancy framework StackExchange) for instance - there has to be many cases where the same object (question, answer, etc) is being updated 'concurrently'. This would be a large consideration of such software i'd imagine.

Answer 5

About all concurrency in web apps is based on multi-user experience. Often it's just "one process per user", with no common denominator and possibly connected only at database level, but apps like Flockdraw, usteream and other that group many users together in realtime, keep them interconnected and synchronized by multiple threads taking load of separate users but interfacing with each other actively in the realtime.

Answer 6

To stick to your question ...

If there was something that was compute intensive it had to happen offline (and the clients could query for the results later or callbacks could be implemented).

This is precisely the part where background concurrency (on the server) is needed sometimes, and preferable to an Ajax-spawned web thread:

• A background computation could be too long for the Session, so you can't use a web thread (you would timeout your Session).
• A background computation may not need to hold much information that is otherwise needed for that user, it may need much less context, which is good for freeing memory.
• Nightly batches might process huge database tables by chunks, and require exclusive access to these tables. Multi-threading might be required to bring computation-time within an acceptable duration (allowing other tasks to follow, or users to access the results after an acceptable duration). It is not uncommon to stop user interactions during a time-frame at night, and process some batches, and mastering the concurrency interactions at that time might be critical.