For this problem, you could either declare those objects volatile, or, perhaps even better, make them Atomic. Check out the docs on atomic variables here: http://java.sun.com/j2se/1.5.0/docs/api/java/util/concurrent/atomic/package-summary.html

This’ll allow you to read and write variables threadsafely, and also to compare and update them – the threading system may decide to switch to another thread in between a comparison and an update of a variable.

Well, it turns out that I’m not the only one. Joe Campbell pointed me toward a well-written article by article by Brian Goetz that describes this problem in detail. Brian is one of the world’s top experts on Java threading — among other things he is the author of “Java Concurrency in Practice”. So I am not confused… there IS a real issue here, and 99% of all web applications are broken.

Ah… apparently I misused the term “copy on write”. I was actually envisioning an immutable data structure held by reference in the (mutable) Session, just as you describe. This works great for threads that do reading (they can work with the copy that was valid when the thread began, even if subsequent updates occur). But I’m still trying to figure out he details for threads that do writes. I don’t quite understand your statement, “Once you add simple Mutex locking to the shared mutable variable, then you’re good to go!” but hopefully I’ll figure it out.

I _do_ wonder why there aren’t more published solutions out there for this problem.

I would love to hear about a servlet container that provides some kind of support *other* than the ability to process the requests one-at-a-time for a user (same as locking on the Session). I was under the impression that neither Tomcat, JBoss, WebSphere nor WebLogic offered that. Am I wrong about one of these, or do you know of another container which does?

As for the “double object creation” issue, I’ll stop by your desk sometime; I’d be interested to hear your ideas.

My personal favorite solution (for the moment) is the one undertaken by Clojure: immutable, persistent (*not* copy-on-write!) data structures referenced by shared mutable refs with concurrency semantics. Unfortunately, to get the full impact of Clojure’s references, you really need a transactional memory model, which isn’t exactly something you can retrofit onto a language. Still, “altering” an immutable data structure and storing the result in a shared mutable field is a lot better than actually modifying a single, shared mutable data structure. Once you add simple Mutex locking to the shared mutable variable, then you’re good to go!

As an aside, persistent data structures are a *lot* better than copy-on-write. They’re both fully-immutable, but copy-on-write is hideously inefficient for write operations since the entire structure must be copied. Persistent data structures share structure between new and old versions. With a fully-persistent data structure (like singly-linked lists), you don’t need to copy anything on write, just make the new head point its tail to the old list. More complicated data structures (like red-black trees) usually end up copying a little more, but almost never the entire structure.

Optimally, a fully-immutable data structure should preserve all of the performance guaranties of its mutable counterpart. This is usually hard to achieve, but when it can be done the results are extremely compelling.

It is certainly possible to provide an implementation within your given container that supports the threading safety that you are looking for. I would even venture to say that in some of the more popular servlet containers it is more then likely to already have been dealt with as an issue in the default implementation of the session.

There are also well known ways to deal with the ‘double’ object creation issues that you outline. I would be interested in talking to you about the problem you are attempting to solve so as to understand if you may be solving a problem that has already been dealt with.

Just my $0.02.
Joe