Concurrency is not such a big Deal ...

Concurrency is not such a big Deal ...

... when it comes to web development

Current Debate

• Java compared to its possible successors (Scala, Clojure, ...)
• Much of the focus is on the concurrency model
• Generally, concurrency (in Java) is really hard to get right, ...

... but for web applications ...

... concurrency is not such a big deal!

Concurrency in web applications

• Most web developers know exactly how to tackle concurrency in web applications.
• It's not that hard.
• But for the fun it, let's have a closer look

• In a web application client requests are handled by the app server concurrently, each in its own thread, possibly distributed among cpu cores.
• These threads may possibly access (read and write) shared state simultaneously
• And concurrency is hard mainly because of mutable state, accessed by different threads simultaneously.

But let's put it another way then:

• Concurrency isn't hard for immutable state and
• Concurrency isn't hard for state that is not accessed by different threads simultaneously (mutable or not)

So, let's have a look at what types of state there are in a typical web application and how it is accessed by different threads:

Types of state in web applications

• State of the current request

• Application state held in the application server or in the web framework

• Conversational state

• Application state persisted to the database (business state)

• "Classical" concurrently accessed state

http://stronglytypedblog.blogspot.com

Summary

• And in web applications most state is of one of these types
• In this sense, Java is quite well prepared for the multi-core future in the field of web applications, although other JVM languages might have the better concurrency model
• Nonetheless, there are some even better arguments than concurrency for some alternative languages, for example expressiveness, conciseness or simply productivity.

• If there is no state, there is no problem.
• Immutable state is not a problem.
• State, that is only accessed by a single thread is no problem.
• State modified in a unit of work/transaction is not a problem.

Summary

"Classical" concurrently accessed state

For example heavy calculations done explicitly concurrently. In web applications, a request might spawn several other threads to do an expensive calculation. This is the "classical" case, where thread programming might surely become hard. This is definitively a situation where Scala or Closure or any other language with a better concurrency model might be appropriate.

In fact, this state is read and mutated highly concurrently. Fortunately, most persistence frameworks support the unit of work pattern: State is replicated from the database for each thread accessing it (as a copy). The thread modifies it and writes it back in a database transaction. Modifying state in this way (in a transaction) is an appropriate concurrency strategy. See also software transactional memory (STM), which is supported e.g. by Clojure.

Application state persisted to the database (business state)

Conversational state

HTTP is stateless. There is no conversational state. There is not even a conversation. Unfortunately, this is not exactly true in most web applications, as most applications will store some kind of conversational state in the HTTP session. This type of state might be accessed simultaneously by multiple threads, but only by threads spawned by the same client. In most applications concurrent access to this state is rare and might be well supported by the web framework. Nonetheless, this is state the developer has to take care of.

State of the current request

This is for example data needed to generate the response of the request, status of the request, and so on. In most cases, this is state only available to a single thread, i.e. not accessed simultaneously. This is guaranteed by all application servers for request state held in the app server. And this is guaranteed by all web frameworks (also with front controller pattern) for request state held there. The developer has to take care not to store request state where it can be accessed by other request threads. This is neither hard to understand nor hard to accomplish.

Application state held in the application server or in the web framework

Examples are ServletContext or web framework settings. This is mostly static state that will be initialized at startup but won't be mutated in the lifetime of the application. Otherwise, the application server/web framework will take care that this state is accessed in a thread-safe way.