[
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: 10.5.3.0, 10.6.1.0
> Environment: Windows XP, same problem occurred using Apache Derby
> 10.5.3.0 and still with the newly release 10.6.1.0 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
> Source)
> at
> org.apache.derby.impl.sql.execute.IndexRowToBaseRowResultSet.getNextRowCore(Unknown
> Source)
> at
> org.apache.derby.impl.sql.execute.NestedLoopJoinResultSet.getNextRowCore(Unknown
> Source)
> 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.
