>>>>> "MM" == Mike Matrigali <[EMAIL PROTECTED]> 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
