db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Knut Anders Hatlen (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (DERBY-4275) Query executions fail when compressing a table using SYSCS_UTIL.SYSCS_COMPRESS_ TABLE
Date Thu, 09 Jun 2011 12:28:59 GMT

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

Knut Anders Hatlen commented on DERBY-4275:
-------------------------------------------

Running the regression test suites didn't reveal any problems with the patch. I'll see if
I can construct a case that runs into problem mentioned in the comment:

		// invalidate any prepared statements that
		// depended on this table (including this one)
		// bug 3653 has threads that start up and block on our lock, but do
		// not see they have to recompile their plan.    We now invalidate earlier
		// however they still might recompile using the old conglomerate id before we
		// commit our DD changes.

The scenario described in the last sentence of that comment, is exactly what's happening when
we see the bug.

I'm not sure why other threads would fail to see that they need to recompile if the invalidation
happens later. They may fail because the conglomerate doesn't exist anymore, but the result
set classes have code that checks if the statement is still valid if an error happens, and
recompiles and reexecutes if it's not valid, so that case is supposed to be handled. But maybe
that code was added after bug 3653 had been fixed, I don't know...

> Query executions fail when compressing a table using SYSCS_UTIL.SYSCS_COMPRESS_ TABLE
> -------------------------------------------------------------------------------------
>
>                 Key: DERBY-4275
>                 URL: https://issues.apache.org/jira/browse/DERBY-4275
>             Project: Derby
>          Issue Type: Bug
>          Components: Store
>    Affects Versions: 10.4.1.3
>            Reporter: Sai Pullabhotla
>            Assignee: Knut Anders Hatlen
>              Labels: derby_triage10_5_2
>         Attachments: CompressDBTest1.java, CompressDBTest2.java, invalidate-after.diff
>
>
> Query executions (SELECT and/or UPDATE) fail with serious exceptions while the table
is being compressed using SYSCS_UTIL.SYSCS_COMPRESS_ TABLE. The compression eventually finishes
normally, but the queries keep failing with the same error until the database is rebooted.
More information about this can be found on the Derby mailing list at http://www.nabble.com/Issue-with-SYSCS_UTIL.SYSCS_COMPRESS_-TABLE-td23892893.html.
The exception stacktrace is below: 
> Caused by: java.sql.SQLException: The conglomerate (71,409) requested does not exist.
>             at org.apache.derby.impl.jdbc.SQLExceptionFactory.getSQLException(Unknown
Source)
>             at org.apache.derby.impl.jdbc.Util.generateCsSQLException(Unknown Source)
>             at org.apache.derby.impl.jdbc.TransactionResourceImpl.wrapInSQLException(Unknown
Source)
>             at org.apache.derby.impl.jdbc.TransactionResourceImpl.handleException(Unknown
Source)
>             at org.apache.derby.impl.jdbc.EmbedConnection.handleException(Unknown Source)
>             at org.apache.derby.impl.jdbc.ConnectionChild.handleException(Unknown Source)
>             at org.apache.derby.impl.jdbc.EmbedStatement.executeStatement(Unknown Source)
>             at org.apache.derby.impl.jdbc.EmbedPreparedStatement.executeStatement(Unknown
Source)
>             at org.apache.derby.impl.jdbc.EmbedPreparedStatement.executeQuery(Unknown
Source)
>             at org.apache.tomcat.dbcp.dbcp.DelegatingPreparedStatement.executeQuery(DelegatingPreparedStatement.java:93)
>             ... 25 more
>         Caused by: ERROR XSAI2: The conglomerate (71,409) requested does not exist.
>             at org.apache.derby.iapi.error.StandardException.newException(Unknown Source)
>             at org.apache.derby.impl.store.access.btree.index.B2IFactory.readConglomerate(Unknown
Source)
>             at org.apache.derby.impl.store.access.RAMAccessManager.conglomCacheFind(Unknown
Source)
>             at org.apache.derby.impl.store.access.RAMTransaction.findExistingConglomerate(Unknown
Source)
>             at org.apache.derby.impl.store.access.RAMTransaction.openScan(Unknown Source)
>             at org.apache.derby.impl.store.access.BackingStoreHashTableFromScan.<init>(Unknown
Source)
>             at org.apache.derby.impl.store.access.RAMTransaction.createBackingStoreHashtableFromScan(Unknown
Source)
>             at org.apache.derby.impl.sql.execute.HashScanResultSet.openCore(Unknown Source)
>             at org.apache.derby.impl.sql.execute.JoinResultSet.openRight(Unknown Source)
>             at org.apache.derby.impl.sql.execute.JoinResultSet.openCore(Unknown Source)
>             at org.apache.derby.impl.sql.execute.JoinResultSet.openCore(Unknown Source)
>             at org.apache.derby.impl.sql.execute.ProjectRestrictResultSet.openCore(Unknown
Source)
>             at org.apache.derby.impl.sql.execute.UnionResultSet.getNextRowCore(Unknown
Source)
>             at org.apache.derby.impl.sql.execute.SortResultSet.getRowFromResultSet(Unknown
Source)
>             at org.apache.derby.impl.sql.execute.SortResultSet.getNextRowFromRS(Unknown
Source)
>             at org.apache.derby.impl.sql.execute.SortResultSet.loadSorter(Unknown Source)
>             at org.apache.derby.impl.sql.execute.SortResultSet.openCore(Unknown Source)
>             at org.apache.derby.impl.sql.execute.SortResultSet.openCore(Unknown Source)
>             at org.apache.derby.impl.sql.execute.BasicNoPutResultSetImpl.open(Unknown
Source)
>             at org.apache.derby.impl.sql.GenericPreparedStatement.execute(Unknown Source)


--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

Mime
View raw message