[
https://issues.apache.org/jira/browse/DERBY-3221?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dyre Tjeldvoll updated DERBY-3221:
----------------------------------
Attachment: derby-3221.prelim.diff
SubShape.properties
The ASSERT reported in a debug build is really a red herring and
not related to the original problem. I think the ASSERT simply is
too strict as it does not allow what would be legal
conversion. Simply modifying the queries so that they explicitly
CAST all INTEGER values to BIGINT seems to remove that
problem (see attached modified_SubShape.properties), and exposes the
original problem with the missing temporary conglomerate. And
that problem is only reported by the prepared statement that is
actually re-executed, so that fits nicely with the DERBY-827
hypothesis.
The new call-stack from the line 57 (insert.test) statement shows
that the missing conglomerate error comes from (re-)using
InsertResultSet.rowHolder. At first I thought the problem was
that close() isn't called on this object in
InsertResultSet.close(), but then I noticed that
normalInsertCore() calls close() on it:
if (rowHolder != null)
{
rowHolder.close();
// rowHolder kept across opens
}
The comment doesn't really make sense since rowHolder, in fact,
is closed. Anyway, the real problem is that code in the beginning
of normalInsertCore() assumes that the comment is true, and only
initializes rowHolder on the first execute:
if (firstExecute && constants.deferred)
{
Properties properties = new Properties();
// Get the properties on the old heap
rowChanger.getHeapConglomerateController().getInternalTablePropertySet(properties);
/*
** If deferred we save a copy of the entire row.
*/
rowHolder = new TemporaryRowHolderImpl(activation,
properties);
rowChanger.setRowHolder(rowHolder);
}
Simply commenting out firstExecute in the if-test (see attached
derby-3221.prelim.diff) makes the repro run without problems. I
have not run any other tests with this change, nor do I know if
this is the right approach. But at least it points to what causes
the problem, and explains why it was introduced by DERBY-827.
> "java.sql.SQLException: The conglomerate (-5) requested does not exist." from
> Derby 10.3.1.4 embedded within Eclipse 3.3 and RAD 7.0
> ------------------------------------------------------------------------------------------------------------------------------------
>
> Key: DERBY-3221
> URL: https://issues.apache.org/jira/browse/DERBY-3221
> Project: Derby
> Issue Type: Bug
> Components: JDBC
> Affects Versions: 10.3.1.4, 10.3.2.1
> Environment: Windows Vista Ubuntu Linux on IBM's VM (RAD 7.0)
> Reporter: Tim Halloran
> Attachments: conlomerate.tar.gz, derby-3221.prelim.diff,
> SubShape.properties
>
>
> We are getting an SQLException when several prepared statement deletes are
> done upon an existing database. As far as we can tell this exception should
> never occur unless (evil) things like deleting the database or editing files
> occurs. This is using the embedded driver within a plug-in inside RAD 7.0
> (and Eclipse 3.3).
> I'm not sure what else to submit that might be helpful.
> java.sql.SQLException: The conglomerate (-5) 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.execute(Unknown Source)
> at sun.reflect.GeneratedMethodAccessor12.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
> at java.lang.reflect.Method.invoke(Unknown Source)
> at
> com.surelogic.sierra.jdbc.LazyPreparedStatementConnection$LazyPreparedStatement.invoke(Unknown
> Source)
> at $Proxy1.execute(Unknown Source)
> at com.surelogic.sierra.jdbc.finding.FindingManager.delete(Unknown Source)
> at
> com.surelogic.sierra.jdbc.finding.ClientFindingManager.updateLocalFindings(Unknown
> Source)
> at
> com.surelogic.sierra.jdbc.project.ClientProjectManager.synchronizeProject(Unknown
> Source)
> at
> com.surelogic.sierra.client.eclipse.jobs.SynchronizeJob.synchronize(Unknown
> Source)
> at com.surelogic.sierra.client.eclipse.jobs.SynchronizeJob.run(Unknown
> Source)
> at org.eclipse.core.internal.jobs.Worker.run(Unknown Source)
> Caused by: ERROR XSAI2: The conglomerate (-5) requested does not exist.
> at org.apache.derby.iapi.error.StandardException.newException(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.sql.execute.TemporaryRowHolderResultSet.getNextRowCore(Unknown
> Source)
> at
> org.apache.derby.impl.sql.execute.TemporaryRowHolderResultSet.getNextRow(Unknown
> Source)
> at org.apache.derby.impl.sql.execute.IndexChanger.finish(Unknown Source)
> at org.apache.derby.impl.sql.execute.IndexSetChanger.finish(Unknown Source)
> at org.apache.derby.impl.sql.execute.RowChangerImpl.finish(Unknown Source)
> at org.apache.derby.impl.sql.execute.UpdateResultSet.open(Unknown Source)
> at org.apache.derby.impl.sql.GenericPreparedStatement.execute(Unknown Source)
> ... 14 more
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
