db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mike Matrigali <mikem_...@sbcglobal.net>
Subject Re: [jira] Commented: (DERBY-3362) ControlRow NPE
Date Tue, 04 Mar 2008 19:03:34 GMT
I will look at this, the intent of the code is as said - it should be a 
noop if the page does not exist.  The way post commit processing works 
it is possible to log work on an existing page, but by the time 
processing can happen the page may have gone away.

Knut Anders Hatlen (JIRA) wrote:
>     [ https://issues.apache.org/jira/browse/DERBY-3362?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12574991#action_12574991
] 
> 
> Knut Anders Hatlen commented on DERBY-3362:
> -------------------------------------------
> 
> The method BTreePostCommit.purgeRowLevelCommittedDeletes() was added
> in 10.3.2.1 (DERBY-3216), which explains why this is not seen on
> 10.3.1.4.
> 
> In that issue, I posted the following question after reviewing the
> code (no answer from the submitter, though):
> 
>> In the same method, I see this piece of code:
>> + if ((controlRow = ControlRow.get(open_btree, page_number)) == null)
>> + return;
>>
>> As far as I can see, it is impossible that ControlRow.get() returns
>> null, so by returning successfully when controlRow is null, we might
>> be hiding future bugs. Wouldn't it be better to skip the null
>> checking and just let the method fail with an NPE when controlRow is
>> dereferenced?
> 
> Looking at it again, I'm wondering if the check is actually there to
> ensure that purgeRowLevelCommittedDeletes() is a no-op if the page
> doesn't exist. However, it is wrong since ControlRow.get() will fail
> instead of returning null if the page cannot be found.
> 
> Would it work if we changed the above mentioned code like this?
> 
> Page p = open_btree.container.getPage(page_number);
> if (p == null) {
>     // page doesn't exist, no rows to reclaim
>     return;
> }
> controlRow = ControlRow.getControlRowForPage();
> 
> In that case, the null check would make sense, and I think the NPE
> would go away.
> 
> 
>> ControlRow NPE
>> --------------
>>
>>                 Key: DERBY-3362
>>                 URL: https://issues.apache.org/jira/browse/DERBY-3362
>>             Project: Derby
>>          Issue Type: Bug
>>    Affects Versions: 10.3.2.1
>>            Reporter: James Alan Shepherd
>>         Attachments: derbylog.zip
>>
>>
>> I have a NPE in Derby 10.3.2.1 (10.3.1.4 does not show this behaviour) that is probably
the same one discussed in DERBY-3216
>> FATAL 38406 [Main] (Start.java:153) - Start FAILED
>> org.springframework.transaction.TransactionSystemException: Could not commit JDBC
transaction; nested exception is java.sql.SQLException: Java exception: ': java.lang.NullPointerException'.
>> Caused by:
>> java.sql.SQLException: Java exception: ': java.lang.NullPointerException'.
>>         at org.apache.derby.impl.jdbc.SQLExceptionFactory40.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.EmbedConnection.commit(Unknown Source)
>>         at org.apache.commons.dbcp.DelegatingConnection.commit(DelegatingConnection.java:238)
>>         at org.apache.commons.dbcp.PoolingDataSource$PoolGuardConnectionWrapper.commit(PoolingDataSource.java:199)
>>         at org.springframework.jdbc.datasource.DataSourceTransactionManager.doCommit(DataSourceTransactionManager.java:245)
>>         at org.springframework.transaction.support.AbstractPlatformTransactionManager.processCommit(AbstractPlatformTransactionManager.java:651)
>>         at org.springframework.transaction.support.AbstractPlatformTransactionManager.commit(AbstractPlatformTransactionManager.java:621)
>>         at org.springframework.transaction.support.TransactionTemplate.execute(TransactionTemplate.java:146)
>>         at com.aaa.bbb.cccFactory$ddd.add(cccFactory.java:324)
>>         at com.aaa.eee.fff.ggg.reload(ggg.java:44)
>>         at com.aaa.eee.fff.ggg.startup(ggg.java:57)
>>         at com.aaa.eee.fff.Start.startupEee(Start.java:170)
>>         at com.aaa.eee.fff.Start.startup(Start.java:146)
>>         at com.aaa.start.Starter.startup(Starter.java:264)
>>         at com.aaa.start.Main.startup(Main.java:270)
>>         at com.aaa.start.Main.main(Main.java:199)
>> Caused by: java.sql.SQLException: Java exception: ': java.lang.NullPointerException'.
>>         at org.apache.derby.impl.jdbc.SQLExceptionFactory.getSQLException(Unknown
Source)
>>         at org.apache.derby.impl.jdbc.SQLExceptionFactory40.wrapArgsForTransportAcrossDRDA(Unknown
Source)
>>         ... 21 more
>> Caused by: java.lang.NullPointerException
>>         at org.apache.derby.impl.store.access.btree.ControlRow.getControlRowForPage(Unknown
Source)
>>         at org.apache.derby.impl.store.access.btree.ControlRow.get(Unknown Source)
>>         at org.apache.derby.impl.store.access.btree.ControlRow.get(Unknown Source)
>>         at org.apache.derby.impl.store.access.btree.BTreePostCommit.purgeRowLevelCommittedDeletes(Unknown
Source)
>>         at org.apache.derby.impl.store.access.btree.BTreePostCommit.performWork(Unknown
Source)
>>         at org.apache.derby.impl.store.raw.xact.Xact.postTermination(Unknown Source)
>>         at org.apache.derby.impl.store.raw.xact.Xact.completeCommit(Unknown Source)
>>         at org.apache.derby.impl.store.raw.xact.Xact.commit(Unknown Source)
>>         at org.apache.derby.impl.store.raw.xact.Xact.commit(Unknown Source)
>>         at org.apache.derby.impl.store.access.RAMTransaction.commit(Unknown Source)
>>         at org.apache.derby.impl.sql.conn.GenericLanguageConnectionContext.doCommit(Unknown
Source)
>>         at org.apache.derby.impl.sql.conn.GenericLanguageConnectionContext.userCommit(Unknown
Source)
>>         at org.apache.derby.impl.jdbc.TransactionResourceImpl.commit(Unknown Source)
>>         ... 15 more
>> and derby.log:
>> 2008-01-28 08:26:36.148 GMT Thread[Main,5,main] (XID = 1888), (SESSIONID = 2), (DATABASE
= directory:myDB), (DRDAID = null), Executing prepared statement: SELECT COUNT(*) FROM ZZZ
WHERE nID IS NULL :End prepared statement
>> 2008-01-28 08:26:36.150 GMT Thread[Main,5,main] (XID = 1888), (SESSIONID = 2), (DATABASE
= directory:myDB), (DRDAID = null), Committing
>> 2008-01-28 08:26:36.188 GMT Thread[Main,5,main] (XID = 1888), (SESSIONID = 2), (DATABASE
= directory:myDB), (DRDAID = null), Cleanup action starting
>> 2008-01-28 08:26:36.188 GMT Thread[Main,5,main] (XID = 1888), (SESSIONID = 2), (DATABASE
= directory:myDB), (DRDAID = null), Failed Statement is: null with 2 parameters begin parameter
#1: 1 :end parameter begin parameter #2: 1 :end param
>> eter
>> java.lang.NullPointerException
>>         at org.apache.derby.impl.store.access.btree.ControlRow.getControlRowForPage(Unknown
Source)
>>         at org.apache.derby.impl.store.access.btree.ControlRow.get(Unknown Source)
>>         at org.apache.derby.impl.store.access.btree.ControlRow.get(Unknown Source)
>>         at org.apache.derby.impl.store.access.btree.BTreePostCommit.purgeRowLevelCommittedDeletes(Unknown
Source)
>>         at org.apache.derby.impl.store.access.btree.BTreePostCommit.performWork(Unknown
Source)
>>         at org.apache.derby.impl.store.raw.xact.Xact.postTermination(Unknown Source)
>>         at org.apache.derby.impl.store.raw.xact.Xact.completeCommit(Unknown Source)
>>         at org.apache.derby.impl.store.raw.xact.Xact.commit(Unknown Source)
>>         at org.apache.derby.impl.store.raw.xact.Xact.commit(Unknown Source)
>>         at org.apache.derby.impl.store.access.RAMTransaction.commit(Unknown Source)
>>         at org.apache.derby.impl.sql.conn.GenericLanguageConnectionContext.doCommit(Unknown
Source)
>>         at org.apache.derby.impl.sql.conn.GenericLanguageConnectionContext.userCommit(Unknown
Source)
>>         at org.apache.derby.impl.jdbc.TransactionResourceImpl.commit(Unknown Source)
>>         at org.apache.derby.impl.jdbc.EmbedConnection.commit(Unknown Source)
>>         at org.apache.commons.dbcp.DelegatingConnection.commit(DelegatingConnection.java:238)
>>         at org.apache.commons.dbcp.PoolingDataSource$PoolGuardConnectionWrapper.commit(PoolingDataSource.java:199)
>>         at org.springframework.jdbc.datasource.DataSourceTransactionManager.doCommit(DataSourceTransactionManager.java:245)
>>         at org.springframework.transaction.support.AbstractPlatformTransactionManager.processCommit(AbstractPlatformTransactionManager.java:651)
>>         at org.springframework.transaction.support.AbstractPlatformTransactionManager.commit(AbstractPlatformTransactionManager.java:621)
>>         at org.springframework.transaction.support.TransactionTemplate.execute(TransactionTemplate.java:146)
>>         at com.aaa.bbb.cccFactory$ddd.add(cccFactory.java:324)
>>         at com.aaa.eee.fff.ggg.reload(ggg.java:44)
>>         at com.aaa.eee.fff.ggg.startup(ggg.java:57)
>>         at com.aaa.eee.fff.Start.startupEee(Start.java:170)
>>         at com.aaa.eee.fff.Start.startup(Start.java:146)
>>         at com.aaa.start.Starter.startup(Starter.java:264)
>>         at com.aaa.start.Main.startup(Main.java:270)
>>         at com.aaa.start.Main.main(Main.java:199)
>> Cleanup action completed
>> This is a long transaction that has suddenly started throwing a NPE.
>> Nothing strange happens during the transaction, but on closing I get
>> the NPE.
>> If I reorder some of the statements in the transaction (keeping
>> functional equivalence) the NPE is sometimes not thrown.
>> I have already moved any table/index create statements to a different (previously
committed) transaction. (I have had a few NPE before and locking issues that led me to this
practice).
>> For a while I thought that shutting down derby after creating tables solved the problem,
but this has been proven false.
>> I have tried to run with a sane version, but then I am blocked by too many DERBY-3360.
>> Also:
>> On occasion the transaction DOES commit. Or seems to, but then Derby becomes unresponsive,
the db files do not grow, but CPU rises and new connections can connect but get no response
to commands. I don't know if this is really connected or not, but I thought I would mention
it, as this unresponsive problem is what I am supposed to be diagnosing. When I say seems
to commit, I mean that sometimes commit returns, sometimes it doesn't. Not very helpful, I
know.
> 


Mime
View raw message