Dirty writes and SimpleThreadScope leaking across contexts [SPR-7463]

[spring-projects-issues]

Dave Syer opened SPR-7463 and commented

Two ApplicationContexts having bean definitions with the same name can share a thread and they will then also share a bean instance. It's a dirty write: the first context to use the thread inserts its version of the bean and the other loses. The consequence is at best a memory leak and at worst a security problem, and in all cases a source of strange application behaviour.

SimpleThreadScope should clear its state on destroy() - it should also segregate it by ApplicationContext.id. It would be nice if it supported destruction callbacks for its beans as well, but at least to be useful in practice it should be a DisposableBean which clears and re-initializes its thread local state when the context closes down.

---

Affects: 3.0 GA

Referenced from: commits 5109501

[spring-projects-issues]

Dave Syer commented

An even simpler change: just make the thread local an instance variable (not static). Can we do this for 3.0.4?

[spring-projects-issues]

Chris Beams commented

Go ahead, please. Won't be hard to back out such a change if there's some issue with this approach. For some reason I couldn't assign this to you... just comment when it's committed.

[spring-projects-issues]

Dave Syer commented

Changed to instance variable from static