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:30:23 GMT
>>>>> "MM" == Mike Matrigali <mikem_app@sbcglobal.net> writes:

    MM> Thanks for the description of the changes.  I have not looked at the 
    MM> patch, just the description so far.  so I have the following question:

Hi Mike, thanks for your feedback.

    MM> I know there is a single point (somewhere in the jdbc entry code) that 
    MM> is used to stop
    MM> multiple threads from accessing the same connection at the same time,
    MM> is it affected by your changes?
Hmm, not sure. 
I based my assumptions on the following comment in ContextManager.java: 

" * The first implementation of the context manager
 * assumes there is only one thread to worry about
 * and that the user(s) of the class only create one
 * instance of ContextManager."

    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.

I guess I should have explained where I got that from. In
ContextService.getCurrentContextManager() it looks like like it is...

That's how I interpret the comment in the beginning of 
ContextService.java, but maybe I misunderstanding something.

    MM> Also what kind of performance gains are you seeing from the change?

For a single client (single record select) I have seen from 6 to 9 % 
increase in throughput. For multiple client there is no visible
increase in throughput.

In the profiler I have seen that the methods in question use less
CPU. In particular, less CPU is spent in resetSavepoints() and
getContext(String). 

-- 
dt


Mime
View raw message