Derby
  1. Derby
  2. DERBY-4479

after rename table a to b then create table a statement execute cause null point exception

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Minor Minor
    • Resolution: Fixed
    • Affects Version/s: 10.0.2.1, 10.1.1.0, 10.2.2.0, 10.3.3.0, 10.4.2.0, 10.5.3.0, 10.6.1.0
    • Fix Version/s: 10.5.3.1, 10.6.1.0
    • Component/s: SQL
    • Labels:
      None
    • Environment:
      Windows XP SP2

      java version "1.5.0_16"
      Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_16-b02)
      Java HotSpot(TM) Client VM (build 1.5.0_16-b02, mixed mode, sharing)
    • Issue & fix info:
      Repro attached

      Description

      step 1 : create original table

      CREATE TABLE BPEL_ARCHIVE (
      EVENT_TIME CHAR(17) NOT NULL,
      BUSINESS_ID VARCHAR(100) NOT NULL,
      EVENT_TYPE INT,
      EVENT_CONTENT BLOB,
      PRIMARY KEY ( EVENT_TIME )
      )

      step 2 : rename original table to backup table
      RENAME TABLE BPEL_ARCHIVE TO BPEL_ARCHIVE_200912171148_200912171148

      step 3 : create original table
      cause error...

      java.sql.SQLException: Java exception: ': java.lang.NullPointerException'.
      at org.apache.derby.impl.jdbc.SQLExceptionFactory.getSQLException(Unknown Source)
      at org.apache.derby.impl.jdbc.Util.newEmbedSQLException(Unknown Source)
      at org.apache.derby.impl.jdbc.Util.javaException(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.EmbedStatement.execute(Unknown Source)
      at org.apache.derby.impl.jdbc.EmbedStatement.executeUpdate(Unknown Source)
      at world.dragon.service.bpel.event.derby.DerbyArchiveEndpoint.switchTargetTable(DerbyArchiveEndpoint.java:295)
      ...................................
      Caused by: java.lang.NullPointerException
      at org.apache.derby.impl.sql.execute.CreateIndexConstantAction.executeConstantAction(Unknown Source)
      at org.apache.derby.impl.sql.execute.CreateConstraintConstantAction.executeConstantAction(Unknown Source)
      at org.apache.derby.impl.sql.execute.CreateTableConstantAction.executeConstantAction(Unknown Source)
      at org.apache.derby.impl.sql.execute.MiscResultSet.open(Unknown Source)
      at org.apache.derby.impl.sql.GenericPreparedStatement.executeStmt(Unknown Source)
      at org.apache.derby.impl.sql.GenericPreparedStatement.execute(Unknown Source)
      ... 28 more

      1. patch.diff
        2 kB
        Bryan Pendleton

        Issue Links

          Activity

          Hide
          Knut Anders Hatlen added a comment -

          Here's a simplified version of the repro:

          ij> create table a (x int not null primary key);
          0 rows inserted/updated/deleted
          ij> rename table a to b;
          0 rows inserted/updated/deleted
          ij> create table a (x int not null primary key);
          ERROR XJ001: Java exception: ': java.lang.NullPointerException'.

          Note that the two CREATE TABLE statements must be identical. Even a simple whitespace change makes the second CREATE TABLE succeed:

          ij> create table a (x int not null primary key);
          0 rows inserted/updated/deleted
          ij> rename table a to b;
          0 rows inserted/updated/deleted
          ij> create table a ( x int not null primary key);
          0 rows inserted/updated/deleted

          This may indicate that the CREATE TABLE statement is not properly invalidated in the statement cache when RENAME TABLE is performed.

          Show
          Knut Anders Hatlen added a comment - Here's a simplified version of the repro: ij> create table a (x int not null primary key); 0 rows inserted/updated/deleted ij> rename table a to b; 0 rows inserted/updated/deleted ij> create table a (x int not null primary key); ERROR XJ001: Java exception: ': java.lang.NullPointerException'. Note that the two CREATE TABLE statements must be identical. Even a simple whitespace change makes the second CREATE TABLE succeed: ij> create table a (x int not null primary key); 0 rows inserted/updated/deleted ij> rename table a to b; 0 rows inserted/updated/deleted ij> create table a ( x int not null primary key); 0 rows inserted/updated/deleted This may indicate that the CREATE TABLE statement is not properly invalidated in the statement cache when RENAME TABLE is performed.
          Hide
          Bryan Pendleton added a comment -

          Attached is my first proposal at resolving this issue.

          As Knut suggested, it appears that the problem involves a missing dependency
          between the CREATE TABLE statement and the table that it is creating.

          For other types of statements, the dependency of the statement on the table
          is generally registered during compilation. For example, here is a snip of code
          from CreateIndexNode.bindStatement:

          /* Statement is dependent on the TableDescriptor */
          getCompilerContext().createDependency(td);

          However, this isn't quite so easy with the CREATE TABLE statement, because
          the table descriptor doesn't exist during compilation, since the table isn't
          created until the statement is actually executed.

          Therefore, the attached patch registers the dependency at execution time. At
          the very end of CreateTableConstantAction.executeConstantAction, there is
          some new code added to register a dependency from the CREATE TABLE
          statement to the table we have just finished creating.

          I haven't yet run the full regression suite, just the repro script. But any feedback
          on the patch at this point is most welcome

          Show
          Bryan Pendleton added a comment - Attached is my first proposal at resolving this issue. As Knut suggested, it appears that the problem involves a missing dependency between the CREATE TABLE statement and the table that it is creating. For other types of statements, the dependency of the statement on the table is generally registered during compilation. For example, here is a snip of code from CreateIndexNode.bindStatement: /* Statement is dependent on the TableDescriptor */ getCompilerContext().createDependency(td); However, this isn't quite so easy with the CREATE TABLE statement, because the table descriptor doesn't exist during compilation, since the table isn't created until the statement is actually executed. Therefore, the attached patch registers the dependency at execution time. At the very end of CreateTableConstantAction.executeConstantAction, there is some new code added to register a dependency from the CREATE TABLE statement to the table we have just finished creating. I haven't yet run the full regression suite, just the repro script. But any feedback on the patch at this point is most welcome
          Hide
          Dag H. Wanvik added a comment -

          This patch makes sense to me. +1

          Show
          Dag H. Wanvik added a comment - This patch makes sense to me. +1
          Hide
          Knut Anders Hatlen added a comment -

          One alternative approach is to stop caching DDL statements that cannot reasonably be expected to be re-executed. The CREATE TABLE statement, for example, cannot be successfully re-executed until the table has been dropped or renamed, in which case the cached statement will have been invalidated anyway. So in effect it just takes up space in the statement cache for no added benefit.

          But the patch looks like an improvement, so +1 from me too.

          Show
          Knut Anders Hatlen added a comment - One alternative approach is to stop caching DDL statements that cannot reasonably be expected to be re-executed. The CREATE TABLE statement, for example, cannot be successfully re-executed until the table has been dropped or renamed, in which case the cached statement will have been invalidated anyway. So in effect it just takes up space in the statement cache for no added benefit. But the patch looks like an improvement, so +1 from me too.
          Hide
          Bryan Pendleton added a comment -

          Thanks Dag and Knut for the reviews and assistance. Committed to the trunk as revision 909176.

          Knut, I think your observation about the usefulness of caching DDL statements that
          are very unlikely to be re-issued is quite valid, and I think it would be a good
          enhancement to pursue in the future. My current itch was to resolve the NPE, so
          I decided this this change was reasonable and straightforward and a good incremental
          improvement and so I committed it.

          I think it would be great if somebody took some time to take a deeper and more
          system-wide look at the overall operation of the statement cache mechanism, but
          I'm afraid I don't have the time to do that right now so I'm marking this issue as resolved.

          Show
          Bryan Pendleton added a comment - Thanks Dag and Knut for the reviews and assistance. Committed to the trunk as revision 909176. Knut, I think your observation about the usefulness of caching DDL statements that are very unlikely to be re-issued is quite valid, and I think it would be a good enhancement to pursue in the future. My current itch was to resolve the NPE, so I decided this this change was reasonable and straightforward and a good incremental improvement and so I committed it. I think it would be great if somebody took some time to take a deeper and more system-wide look at the overall operation of the statement cache mechanism, but I'm afraid I don't have the time to do that right now so I'm marking this issue as resolved.
          Hide
          Mike Matrigali added a comment -

          reopening to backport to 10.5.

          Show
          Mike Matrigali added a comment - reopening to backport to 10.5.
          Hide
          Kathey Marsden added a comment -

          reopen for 10.5 back port

          Show
          Kathey Marsden added a comment - reopen for 10.5 back port
          Hide
          Mike Matrigali added a comment -

          backported fix from trunk to 10.5. passed all tests on ubuntu/jdk16.

          m105_jdk16:9>svn commit
          Sending .
          Sending java/engine/org/apache/derby/impl/sql/execute/CreateTableConstantAction.java
          Sending java/testing/org/apache/derbyTesting/functionTests/tests/lang/RenameTableTest.java
          Transmitting file data ..
          Committed revision 960105.

          Show
          Mike Matrigali added a comment - backported fix from trunk to 10.5. passed all tests on ubuntu/jdk16. m105_jdk16:9>svn commit Sending . Sending java/engine/org/apache/derby/impl/sql/execute/CreateTableConstantAction.java Sending java/testing/org/apache/derbyTesting/functionTests/tests/lang/RenameTableTest.java Transmitting file data .. Committed revision 960105.
          Hide
          Mike Matrigali added a comment -

          reassigning back to original owner.

          Show
          Mike Matrigali added a comment - reassigning back to original owner.
          Hide
          Knut Anders Hatlen added a comment -

          Changed 10.5 fix version to match the version on the branch.

          Show
          Knut Anders Hatlen added a comment - Changed 10.5 fix version to match the version on the branch.
          Hide
          Knut Anders Hatlen added a comment -

          [bulk update] Close all resolved issues that haven't been updated for more than one year.

          Show
          Knut Anders Hatlen added a comment - [bulk update] Close all resolved issues that haven't been updated for more than one year.

            People

            • Assignee:
              Bryan Pendleton
              Reporter:
              dragon lee
            • Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development