db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "A B (JIRA)" <j...@apache.org>
Subject [jira] Issue Comment Edited: (DERBY-3221) "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
Date Thu, 13 Dec 2007 00:19:43 GMT

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

army edited comment on DERBY-3221 at 12/12/07 4:18 PM:
------------------------------------------------------

> I can narrow it down to the inclusion of five rows in the selected set - these rows don't
seem to
> cause any different logic to be followed

I haven't been following this very closely, but the fact that 5 rows is the magic number and
that Mike mentioned temporary files made me think of impl/sql/execute/TemporaryRowHolderImpl.java,
where we have:

public static final int DEFAULT_OVERFLOWTHRESHOLD = 5;

Examination of the code shows that this will be the size of "rowArray" for the TemporaryRowHolder,
and once we reach 5 rows we'll create a temporary conglomerate to store the extra rows.  I
can't be certain, but I *think* that one of the ways in which we use TemporaryRowHolders is
when we update a unique index column, in which case we put the new row into a temporary row
holder, delete the old row, then insert from the temporary row holder.  This indirection allows
correct processing of scenarios when the new (updated) value of one row matches the old value
of another row (by deleting the old row first and *then* inserting new row, we avoid throwing
a duplicate key violation).

Maybe that's related, maybe not.  Just thought I'd mention it since I saw the number 5...



      was (Author: army):
    > I can narrow it down to the inclusion of five rows in the selected set - these rows
don't seem to
> cause any different logic to be followed

I haven't been following this very closely, but the fact that 5 rows is the magic number and
that Mike mentioned temporary files made me think of impl/sql/execute/TemporaryRowHolder,
where we have:

public static final int DEFAULT_OVERFLOWTHRESHOLD = 5;

Examination of the code shows that this will be the size of "rowArray" for the TemporaryRowHolder,
and once we reach 5 rows we'll create a temporary conglomerate to store the extra rows.  I
can't be certain, but I *think* that one of the ways in which we use TemporaryRowHolders is
when we update a unique index column, in which case we put the new row into a temporary row
holder, delete the old row, then insert from the temporary row holder.  This indirection allows
correct processing of scenarios when the new (updated) value of one row matches the old value
of another row (by deleting the old row first and *then* inserting new row, we avoid throwing
a duplicate key violation).

Maybe that's related, maybe not.  Just thought I'd mention it since I saw the number 5...


  
> "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
>         Environment: Windows Vista Ubuntu Linux on IBM's VM (RAD 7.0)
>            Reporter: Tim Halloran
>
> 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.


Mime
View raw message