>>>>> "MM" == Mike Matrigali <mikem_app@sbcglobal.net> writes:
MM> Is it true that each context manager is a thread local variable? With
MM> connection pooling I know that a connection and it's associated context
MM> manager can be executed on a different thread each time it enters
MM> the jdbc stack.
It just occured to me that if multiple threads are allowed to access
the same ContextManager, then the current implementation is broken as
well. The current implementation of pushContext looks like this:
public void pushContext(Context newContext)
{
checkInterrupt();
String contextId = newContext.getIdName();
Stack idStack = (Stack) ctxTable.get(contextId);
// if the stack is null, create a new one.
if (idStack == null)
{
idStack = new Stack();
ctxTable.put(contextId,idStack);
}
// add to top of id's stack
idStack.push(newContext);
// add to top of global stack too
holder.push(newContext);
}
The method itself NOT synchronized, but it updates three fully synchronized
containers (ctxTable, idStack and holder), and there is nothing that
ensures that these three containers are changed together, or not at all.
--
dt
However, experience shows that for many people and many applications a
dose of paranoia is reasonable - Bjarne Stroustrup
|