[
https://issues.apache.org/jira/browse/DERBY-4275?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Knut Anders Hatlen updated DERBY-4275:
--------------------------------------
Attachment: invalidation-during-compilation.diff
I managed to reproduce it in my environment and have been running with an
instrumented build to try to figure out what's going on. It looks to me as if
the problem is that GenericPreparedStatement.makeInvalid() does nothing if the
statement is in the process of being recompiled. That may be fine if the
recompilation has just started, but if it's in the middle of the compilation,
it may end up producing an execution plan that only works with the old
conglomerate.
I've experimented with the attached patch
(invalidation-during-compilation.diff). That patch makes GPS.makeInvalid() set
a flag if it attempted an invalidation during compilation, and
GPS.executeStmt() checks the flag after compilation and requests recompilation
if necessary.
This makes the failure happen less frequently. It appears to completely fix the
situations where makeInvalid() used to swallow the invalidation request and the
recompilation successfully completed using stale meta-data, which caused the
execution of the plan to fail with a conglomerate not found exception. The
stack trace Kristian posted was such a case.
However, there's a variation that's not properly handled by the patch. If the
conglomerate not found exception is thrown by the in-progress recompilation
itself, because the conglomerate disappeared under its feet, something goes
wrong. The patch does make it ignore the exception and recompile once more, the
recompilation succeeds, and so does the execution of the plan. But when the
transaction in which this happened is committed, the following exception is
thrown:
ERROR X0Y66: Cannot issue commit in a nested connection when there is a pending
operation in the parent connection.
Probably the context stack is in a bad state after the conglomerate not found
exception and needs to be restored somehow, but I haven't dug into that yet.
> 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
> Fix For: 10.8.1.6, 10.9.0.0
>
> Attachments: CompressDBTest1.java, CompressDBTest2.java,
> d4275-1a.diff, invalidate-after.diff, invalidation-during-compilation.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
