db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bryan Pendleton (JIRA)" <j...@apache.org>
Subject [jira] Commented: (DERBY-3033) select query results in nullpointer exception in skipScan()
Date Tue, 18 Sep 2007 18:34:43 GMT

    [ 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
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
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

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:
>         Environment: Windows XP, Java 5.0, JDBC, Derby
>            Reporter: Haolan Qin
>            Assignee: Bryan Pendleton
>         Attachments: bug4736.sql, d3033-sane-ij-session-, 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.

View raw message