You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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.
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
The text was updated successfully, but these errors were encountered: