db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Knut Anders Hatlen (JIRA)" <j...@apache.org>
Subject [jira] Commented: (DERBY-2353) intermittent NPEs during DELETE ops in a reasonably large transaction
Date Mon, 02 Feb 2009 14:40:00 GMT

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


Mime
View raw message