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 "Knut Anders Hatlen (JIRA)" <ji...@apache.org> on 2009/02/02 15:40:00 UTC
[jira] Commented: (DERBY-2353) intermittent NPEs during DELETE ops
in a reasonably large transaction
[ 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.