db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dyre Tjeldvoll (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (DERBY-6510) Deby engine threads not making progress
Date Fri, 14 Mar 2014 13:55:42 GMT

    [ https://issues.apache.org/jira/browse/DERBY-6510?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13935037#comment-13935037

Dyre Tjeldvoll commented on DERBY-6510:

On derby-dev I wrote:

??Alternatively, there could be some kind of poor synchronization/race condition causing all
the threads to start repreparing the query simultaneously (for the same reason). So when the
thread tries to acquire the lock, it is blocked until the first thread has finished the long-lasting
prepare, but when it obtains the lock it does not detect that the reprepare is no longer needed
and proceeds with another (unecessary) long-lasting prepare.??

After reading the source I think I can debunk this theory. As the following code snippet shows,
the code does detect the siuation that the statement was prepare by another thread while we
waited for the lock:

{code:title=From GenericStatement.prepMinion(...)|borderStyle=solid}
		synchronized (preparedStmt) 

			for (;;) {

				if (foundInCache) {
					if (preparedStmt.referencesSessionSchema()) {
						// cannot use this state since it is private to a connection.
						// switch to a new statement.
						foundInCache = false;
						preparedStmt = new GenericPreparedStatement(this);

				// did it get updated while we waited for the lock on it?
				if (preparedStmt.upToDate()) {
					return preparedStmt;

                if (!preparedStmt.isCompiling()) {

				try {
				} catch (InterruptedException ie) {


> 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:
>         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
> 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

View raw message