[
https://issues.apache.org/jira/browse/DERBY-2353?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12669613#action_12669613
]
Knut Anders Hatlen commented on DERBY-2353:
-------------------------------------------
I think the problem may be that the NoRowsResultSet family of ResultSets
doesn't know which ResultSet is the top-level ResultSet.
NoPutResultSetImpl.close() makes sure that some code is only executed for the
top node: printing of query plan and closing of activation for single-execution
statements. NoRowsResultSetImpl.close() executes that code for all ResultSets.
So here's what seems to be happening (using the repro from the derby-user
thread): When close() is called on the top-level DeleteCascadeResultSet, it
prints the query plan and closes the activation. Later the close() method of
the child DeleteCascadeResultSet is called (the one that's performing the
cascading delete), and because the activation is closed, the RuntimeStatistics
object is null and we get the NPE when we try to print the query plan.
Note that the activation is only closed by the ResultSet's close() method if
it's a single-execution activation. This means that we won't see the problem if
we're using prepared statements, as they are not single-execution. I verified
this by replacing the following line in the repro script:
delete from collectives;
with
prepare p as 'delete from collectives';
execute p;
and then the statement didn't throw an exception.
I guess we could fix it along these lines:
- make sure that the child DeleteCascadeResultSets don't close the activation
- make sure DeleteCascadeResultSet.cleanUp() cleans up the child ResultSets
before it calls super.cleanUp() (which ends up calling close() and closing the
activation). Right now it closes itself first and then its children.
> intermittent NPEs during DELETE ops in a reasonably large transaction
> ---------------------------------------------------------------------
>
> Key: DERBY-2353
> URL: https://issues.apache.org/jira/browse/DERBY-2353
> Project: Derby
> Issue Type: Bug
> Components: Store
> Affects Versions: 10.2.2.0
> Environment: Seen on both Windows XP and Mac OS X 10.4
> Reporter: Dan Karp
>
> I'm intermittently seeing NPEs thrown while using the embedded driver to
> rewrite several rows in a single transaction. Here's the set of commands
> that were executed on the transaction; the last one is the one that failed:
> SELECT entry_id FROM zimbra.directory WHERE UPPER(zimbra_id) =
> '0F850D84-7096-4534-9389-9D85AFC17E8A' AND entry_type = 'acct'
> DELETE FROM zimbra.directory_attrs WHERE entry_id = 8 AND UPPER(name) =
> 'ZIMBRACONTACTMAXNUMENTRIES'
> INSERT INTO zimbra.directory_attrs (entry_id, name, value) VALUES (8,
> 'zimbraContactMaxNumEntries', '0')
> DELETE FROM zimbra.directory_attrs WHERE entry_id = 8 AND UPPER(name) =
> 'ZIMBRAPREFGALAUTOCOMPLETEENABLED'
> INSERT INTO zimbra.directory_attrs (entry_id, name, value) VALUES (8,
> 'zimbraPrefGalAutoCompleteEnabled', 'FALSE')
> DELETE FROM zimbra.directory_attrs WHERE entry_id = 8 AND UPPER(name) =
> 'ZIMBRAPREFMAILPOLLINGINTERVAL'
> INSERT INTO zimbra.directory_attrs (entry_id, name, value) VALUES (8,
> 'zimbraPrefMailPollingInterval', '5m')
> DELETE FROM zimbra.directory_attrs WHERE entry_id = 8 AND UPPER(name) =
> 'ZIMBRAPREFGROUPMAILBY'
> INSERT INTO zimbra.directory_attrs (entry_id, name, value) VALUES (8,
> 'zimbraPrefGroupMailBy', 'conversation')
> DELETE FROM zimbra.directory_attrs WHERE entry_id = 8 AND UPPER(name) =
> 'ZIMBRAFEATUREVIEWINHTMLENABLED'
> INSERT INTO zimbra.directory_attrs (entry_id, name, value) VALUES (8,
> 'zimbraFeatureViewInHtmlEnabled', 'TRUE')
> DELETE FROM zimbra.directory_attrs WHERE entry_id = 8 AND UPPER(name) =
> 'ZIMBRAPREFMESSAGEVIEWHTMLPREFERRED'
> INSERT INTO zimbra.directory_attrs (entry_id, name, value) VALUES (8,
> 'zimbraPrefMessageViewHtmlPreferred', 'TRUE')
> DELETE FROM zimbra.directory_attrs WHERE entry_id = 8 AND UPPER(name) =
> 'ZIMBRAPREFREADINGPANEENABLED'
> INSERT INTO zimbra.directory_attrs (entry_id, name, value) VALUES (8,
> 'zimbraPrefReadingPaneEnabled', 'TRUE')
> DELETE FROM zimbra.directory_attrs WHERE entry_id = 8 AND UPPER(name) =
> 'ZIMBRAFEATUREGALAUTOCOMPLETEENABLED'
> INSERT INTO zimbra.directory_attrs (entry_id, name, value) VALUES (8,
> 'zimbraFeatureGalAutoCompleteEnabled', 'TRUE')
> DELETE FROM zimbra.directory_attrs WHERE entry_id = 8 AND UPPER(name) =
> 'ZIMBRAPREFCALENDARUSEQUICKADD'
> Here's the stack trace:
> Caused by: java.sql.SQLException: Java exception: ':
> java.lang.NullPointerException'.
> at
> org.apache.derby.impl.jdbc.SQLExceptionFactory.getSQLException(SQLExceptionFactory.java:45)
> at org.apache.derby.impl.jdbc.Util.newEmbedSQLException(Util.java:89)
> at org.apache.derby.impl.jdbc.Util.newEmbedSQLException(Util.java:100)
> at org.apache.derby.impl.jdbc.Util.javaException(Util.java:219)
> at
> org.apache.derby.impl.jdbc.TransactionResourceImpl.wrapInSQLException(TransactionResourceImpl.java:386)
> at
> org.apache.derby.impl.jdbc.TransactionResourceImpl.handleException(TransactionResourceImpl.java:345)
> at
> org.apache.derby.impl.jdbc.EmbedConnection.handleException(EmbedConnection.java:1378)
> at
> org.apache.derby.impl.jdbc.ConnectionChild.handleException(ConnectionChild.java:81)
> at
> org.apache.derby.impl.jdbc.EmbedStatement.executeStatement(EmbedStatement.java:1272)
> at
> org.apache.derby.impl.jdbc.EmbedPreparedStatement.executeStatement(EmbedPreparedStatement.java:1635)
> at
> org.apache.derby.impl.jdbc.EmbedPreparedStatement.executeUpdate(EmbedPreparedStatement.java:299)
> at
> org.apache.commons.dbcp.DelegatingPreparedStatement.executeUpdate(DelegatingPreparedStatement.java:233)
> at
> com.zimbra.cs.db.DebugPreparedStatement.executeUpdate(DebugPreparedStatement.java:154)
> And here's the schema:
> CREATE TABLE directory (
> entry_id INTEGER NOT NULL GENERATED BY DEFAULT AS IDENTITY PRIMARY KEY,
> entry_type CHAR(4) NOT NULL,
> entry_name VARCHAR(128) NOT NULL,
> zimbra_id CHAR(36),
> modified SMALLINT NOT NULL
> );
> CREATE UNIQUE INDEX i_directory_zimbra_id ON directory(zimbra_id);
> CREATE UNIQUE INDEX i_directory_entry_type_name ON directory(entry_type,
> entry_name);
> CREATE TABLE directory_attrs (
> entry_id INTEGER NOT NULL,
> name VARCHAR(255) NOT NULL,
> value VARCHAR(10240) NOT NULL,
> CONSTRAINT fk_dattr_entry_id FOREIGN KEY (entry_id) REFERENCES
> directory(entry_id)
> ON DELETE CASCADE
> );
> CREATE INDEX i_dattr_entry_id_name ON directory_attrs(entry_id, name);
> CREATE INDEX i_dattr_name ON directory_attrs(name);
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
