Nowhere to hide (from) the Evil State

There has been some warnings sometime already from gurus, bloggers and article writers that we will have to get a lot more careful regarding writing code that is thread-safe. Most of the time programmers do it right, not necessarily because they have understood the whole problem, but because the default singleton behavior of the Spring framework forces them to.

On the other hand some old sins comes into the spotlight these days. Code that was written when developers only had single cpu-machines, and the multi-cpu machines really was not fast enough to uncover all potential problems.

Now developers has discovered what they can do with multi-cores and start writing new code utilizing them. The problem is that they reuse older code that was not developed with this in mind.
Most code handles data belonging to different users correctly. The problems often arises when code is executed multithreaded on behalf of a single user. Then there is nowhere to safely store state without lock-management anymore. Not even the database safe. It is no longer safe to assume that even a database only used by 1 system that rows "belonging" to a specific user can be updated without proper lock handling.

The old saying that "State is Evil" (wondering who said that?) has got a new renaissance. All objects belonging to the HttpSession must be managed properly for instance. I can see this can become challenging in a JSF application if you have the model is JSF managed beans. JSF does not let you (easily) replace the value of a managed bean. Guess there is some API's, but are they thread safe?
This means that if multiple threads is given access to controller- or model beans there must be proper locking on updates to the model.