db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dyre.Tjeldv...@Sun.COM
Subject Re: [jira] Commented: (DERBY-938) ContextManager needs to be optimized
Date Thu, 09 Feb 2006 18:58:25 GMT
>>>>> "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


Mime
View raw message