[
https://issues.apache.org/jira/browse/DERBY-6510?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13935490#comment-13935490
]
Mike Matrigali commented on DERBY-6510:
---------------------------------------
I am not familar with this. Do the queries that end up at derby have "?"
parameters? The derby statement
cache only treats 2 statements as the same if the text is identical. This is
going to true of inserts also. Same
question about the inserts. If they don't have "?" params then I would not be
surprised if they are flooding
the statement cache and quickly invalidating other statements.
>The actual query is generated by EclipseLink version 1.13 (JPA). It is not
>prepared before hand but and does
>count on derby caching it once compiled. Yesterday that query had been
>performed (as part of the web >service request processig) 125 times before the
>system was hard reset.
The query's that you have most recently been posting the result query plans
look like they have their parameters inline'd in the text. Does that match
exactly what is going on in the application? Note that
the costing code path is actually different for queries with "?" params vs
those with the params inlined
in the text.
> Deby engine threads not making progress
> ---------------------------------------
>
> Key: DERBY-6510
> URL: https://issues.apache.org/jira/browse/DERBY-6510
> Project: Derby
> Issue Type: Bug
> Components: Network Server
> Affects Versions: 10.9.1.0
> Environment: Oracle Solaris 10/9, Oracle M5000 32 CPU, 128GB memory,
> 8GB allocated to Derby Network Server
> Reporter: Brett Bergquist
> Priority: Critical
> Attachments: dbstate.log, derbystacktrace.txt, prstat.log,
> prstat_normal.log, queryplan.txt, queryplan_nooptimizerTimeout.txt
>
>
> We had an issue today in a production environment at a large customer site.
> Basically 5 database interactions became stuck and are not progressing.
> Part of the system dump performs a stack trace every few seconds for a period
> of a minute on the Glassfish application server and the Derby database engine
> (running in network server mode). Also, the dump captures the current
> transactions and the current lock table (ie. syscs_diag.transactions and
> syscs_diag.lock_table). We had to restart the system and in doing so, the
> Derby database engine would not shutdown and had to be killed.
> The stack traces of the Derby engine show 5 threads that are basically making
> no progress in that at each sample, they are at the same point, waiting.
> I will attach the stack traces as well as the state of the transactions and
> locks.
> Interesting is that the "derby.jdbc.xaTransactionTimeout =1800" is set, yet
> the transactions did not timeout. The timeout is for 30 minutes but the
> transactions were in process for hours.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
