db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Kathey Marsden (JIRA)" <derby-...@db.apache.org>
Subject [jira] Commented: (DERBY-389) With Network Server Database hangs after some time with many connections executing prepareStatement()
Date Fri, 24 Jun 2005 23:43:57 GMT
    [ 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?


     * 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.


*  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)
                    if (foundInCache)

> 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:,
>     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:
For more information on JIRA, see:

View raw message