[
https://issues.apache.org/jira/browse/DERBY-3033?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12528498
]
Bryan Pendleton commented on DERBY-3033:
----------------------------------------
Hi Army, thanks for the feedback! I marked the issue as assigned to me, because
I'm trying to understand it, but progress is slow.
I believe that the null value in row[rsNumber] is coming from a request to
fetch column 1 of result set 5. Here's the original query for context:
select study_id, number_of_images from (select distinct st.study_id,
st.number_of_images, dsr.priority, st.creation_datetime from
dicom_send_requests dsr,
studies st where dsr.send_date is null and dsr.workstation_id = ? and
dsr.study_id = st.study_id and not exists ( select 1 from
dispatcher_locks where
dispatcher_locks.study_id = st.study_id and
dispatcher_locks.workstation_id = ? and
dispatcher_locks.dispatcher_id = ? )) temp
Result set 5, I believe, is the "select 1 from dispatcher_locks" nested query,
and column 1
of that result set is dispatcher_locks.study_id.
The null value occurs at the very beginning of the first time that we are
opening a TableScanResultSet.
We are setting up a NestedLoopJoinResultSet, and the right side of that join is
a index-to-base probe,
and so we are trying to set the start position for a particular "probe" into
the index for a particular
study_id value. sameStartStopPosition is true, as the join on study_id is a
simple equality join.
The code in question, near the top of TableScanResultSet.openCore(), is:
if (startKeyGetter != null)
{
startPosition = (ExecIndexRow)
startKeyGetter.invoke(activation);
if (sameStartStopPosition)
{
stopPosition = startPosition;
}
}
if (stopKeyGetter != null)
{
stopPosition = (ExecIndexRow)
stopKeyGetter.invoke(activation);
}
The TableScanResultSet instance that we are processing is for an index-to-base
probe of
the dicom_send_requests table via the sendreq_study_id_fk secondary index.
I'm thinking that, although the external form of the SQL SELECT statement is:
- dicom_send_requests joins to studies on study_id, and
- studies joins to dispatcher_locks on study_id
the optimizer may have re-arranged this and selected a different join order so
that the actual
query is more like:
- dispatcher_locks joins to dicom_send_requests on study_id, and
- dicom_send_requests joins to studies on study_id
And then, perhaps because the dispatcher_locks query is a "select 1" query, the
execution of the query against dispatcher_locks hasn't fetched any actual data,
and so
the column is coming back null.
So far, however, I haven't seen any code path that is going
through NoPutResultSetImpl.clearOrderableCache, so I don't any information
to share regarding the code comment that Kathey observed.
> select query results in nullpointer exception in skipScan()
> -----------------------------------------------------------
>
> Key: DERBY-3033
> URL: https://issues.apache.org/jira/browse/DERBY-3033
> Project: Derby
> Issue Type: Bug
> Components: SQL
> Affects Versions: 10.2.2.0
> Environment: Windows XP, Java 5.0, JDBC, Derby 10.2.2.0
> Reporter: Haolan Qin
> Assignee: Bryan Pendleton
> Attachments: bug4736.sql, d3033-sane-ij-session-10.3.1.5.txt,
> query_plan.new, query_plan.old, test.rar, test.zip, viewer_10_1.zip
>
>
> The following error was repeatedly thrown when we tried to run a select query
> via JDBC. Strangely, the exact same select query did not trigger any error
> when run from the command line console. After we added an index, the error
> went away completely.
> java.lang.NullPointerException
> at org.apache.derby.impl.sql.execute.NoPutResultSetImpl.skipScan(Unknown
> Source)
> at org.apache.derby.impl.sql.execute.TableScanResultSet.openCore(Unknown
> Source)
> at
> org.apache.derby.impl.sql.execute.IndexRowToBaseRowResultSet.openCore(Unknown
> Source)
> at
> org.apache.derby.impl.sql.execute.ProjectRestrictResultSet.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.ProjectRestrictResultSet.openCore(Unknown
> Source)
> at org.apache.derby.impl.sql.execute.SortResultSet.openCore(Unknown Source)
> at
> org.apache.derby.impl.sql.execute.ProjectRestrictResultSet.openCore(Unknown
> Source)
> at org.apache.derby.impl.sql.execute.BasicNoPutResultSetImpl.open(Unknown
> Source)
> at org.apache.derby.impl.sql.GenericPreparedStatement.execute(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 org.apache.derby.impl.drda.DRDAStatement.execute(Unknown Source)
> at org.apache.derby.impl.drda.DRDAConnThread.processCommands(Unknown Source)
> at org.apache.derby.impl.drda.DRDAConnThread.run(Unknown Source)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
