Expensive cursor name lookup in network server
----------------------------------------------
Key: DERBY-3882
URL: https://issues.apache.org/jira/browse/DERBY-3882
Project: Derby
Issue Type: Improvement
Components: Network Server, Performance, SQL
Affects Versions: 10.4.2.0
Reporter: Knut Anders Hatlen
Priority: Minor
I have sometimes seen in a profiler that an unreasonably high amount of the CPU
time is spent in GenericLanguageConnectionContext.lookupCursorActivation() when
the network server is running. That method is used to check that there is no
active statement in the current transaction with the same cursor name as the
statement currently being executed, and it is normally only used if the
executing statement has a cursor name. None of the client-side statements had a
cursor name when I saw this.
The method is always called when the network server executes a statement
because the network server assigns a cursor name to each statement even if no
cursor name has been set on the client side. If the list of open statements is
short, the method is relatively cheap. If one uses
ClientConnectionPoolDataSource with the JDBC statement cache, the list of open
statements can however be quite long, and lookupCursorActivation() needs to
spend a fair amount of time iterating over the list and comparing strings.
The time spent looking for duplicate names in lookupCursorActivation() is
actually wasted time when it is called from the network server, since the
network server assigns unique names to the statements it executes, even when
there are duplicate names on the client. It would be good if we could reduce
the cost of this operation, or perhaps eliminate it completely when the client
doesn't use cursor names.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
