[
http://issues.apache.org/jira/browse/DERBY-389?page=comments#action_12314445 ]
Kathey Marsden commented on DERBY-389:
--------------------------------------
QUESTION ON JAVADOC FOR GenericLanguageConnectionContext.removeStatement()
removeStatement() removes statements from the cache and seems to only be
called when an SQLException occurs on prepare. This makes sense in the context
that Rajesh's test had lots of failed statements and those were probably
causing DERBY-389 to occur.
The javadoc for this method says something else entirely and seems kind
of misleading. It talks about statements in the SESSION schema (temp table
schema) getting removed. I don't see this method being called
for any special handling of temp tables and based on the comment it
sounds like it would be a bad thing for those statements to be in the
cache at all.
I want to change the javadoc comment to take out the reference to the SESSION
schema. Does anyone have any issues with this change? Am I missing an
important piece of history or misunderstanding the use of this method?
OLD JAVADOC
/**
* This method will get called if the statement is referencing
tables in SESSION schema.
* We do not want to cache such statements because multiple
connections can have
* different definition of the same table name and hence compiled
plan for one connection
* may not make sense for some other connection. Because of this,
remove the statement from the cache
*
* @exception StandardException thrown if lookup goes wrong.
*/
NEW JAVADOC
/**
* This method will remove a statement from the statement cache.
* It will be called, for example, if there is an exception preparing
* the statement.
*
* @param statement Statement to remove
* @exception StandardException thrown if lookup goes wrong.
*/
THE ONE removeStatement REFERENCE
from GenericStatement.prepMinion()
....
catch (StandardException se)
{
lcc.commitNestedTransaction();
if (foundInCache)
((GenericLanguageConnectionContext)lcc).removeStatement(this);
.....
> With Network Server Database hangs after some time with many connections
> executing prepareStatement()
> -----------------------------------------------------------------------------------------------------
>
> Key: DERBY-389
> URL: http://issues.apache.org/jira/browse/DERBY-389
> Project: Derby
> Type: Bug
> Components: JDBC, Network Server
> Versions: 10.1.1.0, 10.2.0.0
> Reporter: Kathey Marsden
> Assignee: Kathey Marsden
> Priority: Critical
> Attachments: RTINFO.txt, derby.log, javacore.20050622.135027.2491.txt,
> javacore.20050623.150509.22394.txt
>
> Rajesh found this issue in running Network Server system tests for the 10.1
> release candidate
> While running the Network Server system test with 210 clients,
> the Network Server and all the clients hangs after some time.
> A Ctrl+\ on the Network Server shows that upto 180 threads
> waiting on the PreparedStatements to compile and comes from the
> embedded engine. The following is the stack trace from the java
> dump.
> 3XMTHREADINFO "DRDAConnThread_181" (TID:1007C998,
> sys_thread_t:85C4478, state:CW, native ID:4575ABB0) prio=5
> 4XESTACKTRACE at java.lang.Object.wait(Native Method)
> 4XESTACKTRACE at
> java.lang.Object.wait(Object.java(Compiled Code))
> 4XESTACKTRACE at
> org.apache.derby.impl.sql.GenericStatement.prepMinion(GenericSta
> tement.java(Compiled Code))
> 4XESTACKTRACE at
> org.apache.derby.impl.sql.GenericStatement.prepare(GenericStatem
> ent.java)
> 4XESTACKTRACE at
> org.apache.derby.impl.sql.conn.GenericLanguageConnectionContext.
> prepareInternalStatement(GenericLanguageConnectionContext.java)
> 4XESTACKTRACE at
> org.apache.derby.impl.jdbc.EmbedPreparedStatement.<init>(Embe
> dPreparedStatement.java)
> 4XESTACKTRACE at
> org.apache.derby.impl.jdbc.EmbedPreparedStatement20.<init>(Em
> bedPreparedStatement20.java)
> 4XESTACKTRACE at
> org.apache.derby.impl.jdbc.EmbedPreparedStatement30.<init>(Em
> bedPreparedStatement30.java)
> 4XESTACKTRACE at
> org.apache.derby.jdbc.Driver30.newEmbedPreparedStatement(Driver3
> 0.java)
> 4XESTACKTRACE at
> org.apache.derby.impl.jdbc.EmbedConnection.prepareStatement(Embe
> dConnection.java)
> 4XESTACKTRACE at
> org.apache.derby.impl.jdbc.EmbedConnection.prepareStatement(Embe
> dConnection.java)
> 4XESTACKTRACE at
> sun.reflect.GeneratedMethodAccessor3.invoke(Unknown Source)
> 4XESTACKTRACE at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethod
> AccessorImpl.java(Compiled Code))
> 4XESTACKTRACE at
> java.lang.reflect.Method.invoke(Method.java(Compiled Code))
> 4XESTACKTRACE at
> org.apache.derby.impl.drda.DRDAStatement.prepareStatementJDBC3(D
> RDAStatement.java)
> 4XESTACKTRACE at
> org.apache.derby.impl.drda.DRDAStatement.prepare(DRDAStatement.j
> ava)
> 4XESTACKTRACE at
> org.apache.derby.impl.drda.DRDAStatement.explicitPrepare(DRDASta
> tement.java(Compiled Code))
> 4XESTACKTRACE at
> org.apache.derby.impl.drda.DRDAConnThread.parsePRPSQLSTT(DRDACon
> nThread.java(Compiled Code))
> 4XESTACKTRACE at
> org.apache.derby.impl.drda.DRDAConnThread.processCommands(DRDACo
> nnThread.java(Compiled Code))
> 4XESTACKTRACE at
> org.apache.derby.impl.drda.DRDAConnThread.run(DRDAConnThread.jav
> a)
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
