[
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
