You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-dev@db.apache.org by "Bryan Pendleton (JIRA)" <ji...@apache.org> on 2018/02/01 04:54:00 UTC

[jira] [Commented] (DERBY-6981) SQLSTATE: XJ001, SQLERRMC: java.lang.NullPointerExceptionXJ001.U

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

Bryan Pendleton commented on DERBY-6981:
----------------------------------------

I don't fully understand what's going wrong here, but I (sort of) know how to fix it.

The problem involves:
 # The use of a CONCUR_UPDATABLE result set and a SELECT ... FOR UPDATE statement, which triggers some tricky code in TableScanResultSet
 # The fact that we execute the query multiple times, closing and reopening result sets on the same prepared statement
 # A bug (I think) in the TableScanResultSet.close() logic.

 

The tricky code in TableScanResultSet is very very old code:
{code:java}
/** 
 * This field is used by beetle 3865, updateable cursor using index. It 
 * is a hash table containing updated rows that are thrown into future 
 * direction of the index scan, and as a result we'll hit it again but 
 * should skip it. The hash table will spill to disk if it grows too big 
 * to be kept in memory. 
 */ 
protected BackingStoreHashtable past2FutureTbl;
{code}
And the bug (I think) in TableScanResultSet.close() is that when the past2FutureTbl object is lazy-initialized, so when we close() it, we also have to null out the variable, so that the next time we reopen this result set, we will re-allocate and re-initialize a new past2FutureTbl hashtable.

That is, I think the fix is:
{code:java}
Index: java/engine/org/apache/derby/impl/sql/execute/TableScanResultSet.java =================================================================== 
--- java/engine/org/apache/derby/impl/sql/execute/TableScanResultSet.java (revision 1805254) 
+++ java/engine/org/apache/derby/impl/sql/execute/TableScanResultSet.java (working copy) 
@@ -625,6 +625,7 @@
 if (past2FutureTbl != null)
 { 
past2FutureTbl.close(); 
+ past2FutureTbl = null;
 }
 }
 else
{code}
 

I haven't run any real tests on this, just verified that if I null-out past2FutureTbl at this point, this particular test case passes.

 

Rick, what do you think?

> SQLSTATE: XJ001, SQLERRMC: java.lang.NullPointerExceptionXJ001.U
> ------------------------------------------------------------------
>
>                 Key: DERBY-6981
>                 URL: https://issues.apache.org/jira/browse/DERBY-6981
>             Project: Derby
>          Issue Type: Bug
>          Components: JDBC
>    Affects Versions: 10.12.1.1
>         Environment: OSX,CentOS
>            Reporter: Roger Sanghee Kim
>            Priority: Major
>              Labels: newbie
>         Attachments: Main.java, Test1.zip, derby-test.java, test1.java
>
>
> Original error mesage:
>  
> {code:java}
> java.sql.SQLException: DERBY SQL error: ERRORCODE: 0, SQLSTATE: XJ001, SQLERRMC: java.lang.NullPointerExceptionXJ001.U at org.apache.derby.client.am.SQLExceptionFactory.getSQLException(Unknown Source) at org.apache.derby.client.am.SqlException.getSQLException(Unknown Source) at org.apache.derby.client.am.ClientResultSet.next(Unknown Source) at org.ziptie.provider.credentials.internal.test1.main(test1.java:43) Caused by: ERROR XJ001: DERBY SQL error: ERRORCODE: 0, SQLSTATE: XJ001, SQLERRMC: java.lang.NullPointerExceptionXJ001.U at org.apache.derby.client.am.ClientResultSet.completeSqlca(Unknown Source) at org.apache.derby.client.net.NetResultSetReply.parseFetchError(Unknown Source) at org.apache.derby.client.net.NetResultSetReply.parseCNTQRYreply(Unknown Source) at org.apache.derby.client.net.NetResultSetReply.readFetch(Unknown Source) at org.apache.derby.client.net.ResultSetReply.readFetch(Unknown Source) at org.apache.derby.client.net.NetResultSet.readFetch_(Unknown Source) at org.apache.derby.client.net.NetResultSet.flowFetch(Unknown Source) at org.apache.derby.client.net.NetCursor.getMoreData_(Unknown Source) at org.apache.derby.client.am.Cursor.stepNext(Unknown Source) at org.apache.derby.client.am.Cursor.next(Unknown Source) at org.apache.derby.client.am.ClientResultSet.nextX(Unknown Source)
> {code}
> DERBY-6735 is very similar bug.
> DDL
>  
> {code:java}
> CREATE TABLE TEST1
> (
> ID int PRIMARY KEY NOT NULL,
> LASTUPDATE timestamp
> ){code}
>  
> I have attached test Code:[^derby-test.java]
> test Code with embeded derby : [^Main.java]
> ^Full code on my intellij : [^Test1.zip]:^
> Another database (PostgreSQL) has no problem.
> I also put a workaround in the code.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)