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-4676) NullPointerException on SELECT on INNER JOIN
Date Thu, 27 May 2010 13:04:28 GMT

    [ https://issues.apache.org/jira/browse/DERBY-4676?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12872208#action_12872208

Knut Anders Hatlen commented on DERBY-4676:

Hi Bryan,

'Yes' is the answer to all you questions above.

fetch() first latches the heap page on which the indexed row is supposed to be found. Then
it attempts to lock the row.

If the row cannot be locked immediately, the latch is released before the thread is suspended
while it waits for the lock to be obtained. Once it wakes up again, it will re-obtain the
latch on the heap page. OpenConglomerate.latchPage() additionally checks if the row is still
present on the page, and if it isn't, it will release the latch again and return false. OpenConglomerate.lockPositionForRead/Write
however doesn't check the return value from latchPage() and doesn't distinguish between the
case where the latch was successfully re-obtained and the case where it was not.

Another simpler fix than what I suggested above, would be to check if pos.current_page is
null after the attempt to lock the row, and assume that this means the row (or the entire
page) is gone. In that case we should update the javadoc comment for lockPositionForRead()
to state that this is how it behaves, and remove the sentence that incorrectly states that
it raises an exception.

> NullPointerException on SELECT on INNER JOIN
> --------------------------------------------
>                 Key: DERBY-4676
>                 URL: https://issues.apache.org/jira/browse/DERBY-4676
>             Project: Derby
>          Issue Type: Bug
>    Affects Versions:,
>         Environment: Windows XP, same problem occurred using Apache Derby and
still with the newly release version.   
> For completeness, also noting using c3p0 0.9.1-pre10 and hibernate 3.0.5.   Attempted
trying later versions of both (c3p0 and hibernate) to see if this resulted in a workaround,
but had no success.
>            Reporter: Seth Katzman
>         Attachments: 2010-05-25-applicationerror.log, 2010-05-25-derbyerror.log, D4676.java,
derbyerror.log, error.log
> Running into a NullPointerException error in the Apache Derby database over multiple
versions of the derby jars.  From testing, this issue intermittently occurs during moderate
load test scenarios, but has never occurred in production.   This is using Derby as embedded
and always occurs on the same statement as shown below and in the attachment.   Following
the error, hibernate throws an exception which results in the code attempting to rollback
the transaction.  The rollback fails as the NullPointerException appears to kill the connection.
> *** derby.log 
> 2010-04-27 16:05:22.429 GMT Thread[SNMPDelayedStoreRunnable2Thread,5,main] (XID = 244546),
(SESSIONID = 17), (DATABASE = db), (DRDAID = null), Cleanup action starting
> 2010-04-27 16:05:22.429 GMT Thread[SNMPDelayedStoreRunnable2Thread,5,main] (XID = 244546),
(SESSIONID = 17), (DATABASE = db), (DRDAID = null), Failed Statement is: select nonprimary0_.componentid
as componen1_1_, nonprimary0_.deviceid as deviceid1_, device1_.deviceid as deviceid0_, device1_.name
as name3_0_, device1_.description as descript3_3_0_, device1_.device_type as device4_3_0_,
device1_.managed_address as managed5_3_0_, device1_.csid as csid3_0_, device1_.url as url3_0_,
device1_.date_written_to_db as date8_3_0_, device1_.valid as valid3_0_, device1_.invalid_reason
as invalid10_3_0_, device1_.version as version3_0_ from subsystem_callserver_map nonprimary0_
inner join device_data device1_ on nonprimary0_.deviceid=device1_.deviceid where nonprimary0_.componentid=?
with 1 parameters begin parameter #1: 86b5b069-ca5c-4c38-9643-d9308c246100 :end parameter

> java.lang.NullPointerException
> 	at org.apache.derby.impl.store.access.conglomerate.GenericConglomerateController.fetch(Unknown
> 	at org.apache.derby.impl.sql.execute.IndexRowToBaseRowResultSet.getNextRowCore(Unknown
> 	at org.apache.derby.impl.sql.execute.NestedLoopJoinResultSet.getNextRowCore(Unknown
> 	at org.apache.derby.impl.sql.execute.BasicNoPutResultSetImpl.getNextRow(Unknown Source)
> 	at org.apache.derby.impl.jdbc.EmbedResultSet.movePosition(Unknown Source)
> 	at org.apache.derby.impl.jdbc.EmbedResultSet.next(Unknown Source)
> 	at com.mchange.v2.c3p0.impl.NewProxyResultSet.next(NewProxyResultSet.java:2859)
> 	at org.hibernate.loader.Loader.doQuery(Loader.java:408)
> 	at org.hibernate.loader.Loader.doQueryAndInitializeNonLazyCollections(Loader.java:218)
> 	at org.hibernate.loader.Loader.loadCollection(Loader.java:1434)
> 	at org.hibernate.loader.collection.CollectionLoader.initialize(CollectionLoader.java:99)
> 	at org.hibernate.persister.collection.AbstractCollectionPersister.initialize(AbstractCollectionPersister.java:488)
> 	at org.hibernate.event.def.DefaultInitializeCollectionEventListener.onInitializeCollection(DefaultInitializeCollectionEventListener.java:60)
> 	at org.hibernate.impl.SessionImpl.initializeCollection(SessionImpl.java:1430)
> 	at org.hibernate.collection.AbstractPersistentCollection.forceInitialization(AbstractPersistentCollection.java:280)
> 	at org.hibernate.engine.PersistenceContext.initializeNonLazyCollections(PersistenceContext.java:796)
> 	at org.hibernate.loader.Loader.doQueryAndInitializeNonLazyCollections(Loader.java:223)
> 	at org.hibernate.loader.Loader.doList(Loader.java:1593)
> 	at org.hibernate.loader.Loader.list(Loader.java:1577)
> 	at org.hibernate.loader.hql.QueryLoader.list(QueryLoader.java:395)
> 	at org.hibernate.hql.ast.QueryTranslatorImpl.list(QueryTranslatorImpl.java:271)
> 	at org.hibernate.impl.SessionImpl.list(SessionImpl.java:844)
> 	at org.hibernate.impl.QueryImpl.list(QueryImpl.java:74)
> 	at ooad.p.ga(p.java:288)
> 	at ooad.p.ga(p.java:117)
> 	at oo.c.gdc(c.java:119)
> 	at oo.d.c(d.java:805)
> 	at oo.d.c(d.java:785)
> 	at oo.d.c(d.java:766)
> 	at oodb.s.run(s.java:82)
> 	at java.lang.Thread.run(Thread.java:595)
> *** application log
> Apr 27 2010 12:05:22.476 -0400: %_JDBCExceptionReporter-3-org.hibernate.util.JDBCExceptionReporter:
 Java exception: ': java.lang.NullPointerException'.  
> Apr 27 2010 12:05:22.492 -0400: %_JDBCTransaction-3-org.hibernate.transaction.JDBCTransaction:
 JDBC rollback failed  
> java.sql.SQLException: No current connection.
> 	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.newEmbedSQLException(Unknown Source)
> 	at org.apache.derby.impl.jdbc.Util.noCurrentConnection(Unknown Source)
> 	at org.apache.derby.impl.jdbc.EmbedConnection.checkIfClosed(Unknown Source)
> 	at org.apache.derby.impl.jdbc.EmbedConnection.setupContextStack(Unknown Source)
> 	at org.apache.derby.impl.jdbc.EmbedConnection.rollback(Unknown Source)
> 	at com.mchange.v2.c3p0.impl.NewProxyConnection.rollback(NewProxyConnection.java:755)
> 	at org.hibernate.transaction.JDBCTransaction.rollbackAndResetAutoCommit(JDBCTransaction.java:163)
> 	at org.hibernate.transaction.JDBCTransaction.rollback(JDBCTransaction.java:142)
> 	at ooad.p.r(p.java:888)
> 	at ooad.p.ga(p.java:310)
> 	at ooad.p.ga(p.java:117)
> 	at oa.c.gdc(c.java:119)
> 	at oa.d.c(d.java:805)
> 	at oa.d.c(d.java:785)
> 	at oa.d.c(d.java:766)
> 	at ooad.s.run(s.java:82)
> 	at java.lang.Thread.run(Thread.java:595)

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message