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-707) providing RowLocation for deleted+purged row to GenericConglomerateController causes nullpointerexception
Date Tue, 15 Nov 2005 18:27:10 GMT
This looks like a reasonable fix, it would be nice if you added a test
case which showed the problem (to make sure it does not get broken again
in the future).  If it were me I would add a short new test case to the
T_AccessFactory tests in
opensource/java/testing/org/apache/derbyTesting/unitTests/store.  I know
you have a test case you can't check in as it is the feature you are
working on.  If you are not interested in doing this, let me know.

Andreas Korneliussen (JIRA) wrote:

>     [ http://issues.apache.org/jira/browse/DERBY-707?page=comments#action_12357711 ]

> Andreas Korneliussen commented on DERBY-707:
> --------------------------------------------
> The attached files addresses this issue by checking the return value from open_conglom.latchPage(..)
in GenericConglomerateController. Previously the return value has only been used in one of
the four calls to open_conglom.latchPage(..) in this file, the patch also does the same for
all three other places this is called (fetch, delete and replace).
> Please review if this could be an appropriate patch for the problem reported. 
>>providing RowLocation for deleted+purged row to GenericConglomerateController causes
>>         Key: DERBY-707
>>         URL: http://issues.apache.org/jira/browse/DERBY-707
>>     Project: Derby
>>        Type: Bug
>>  Components: Store
>> Environment: Java 1.4
>>    Reporter: Andreas Korneliussen
>>    Assignee: Andreas Korneliussen
>>    Priority: Minor
>> Attachments: DERBY-707.diff, DERBY-707.stat
>>To provide scrollable updatable resultsets, we will store the RowLocation for every
row in the ResultSet in a temporary table (backingstore hashtable).  The RowLocation is used
to reposition the cursor before an update.
>>The problem is when the row for the RowLocation has been deleted and purged by another
transaction.  The update will then fail with a NullPointerException in GenericConglomerateController.replace(..):
>>        at org.apache.derby.impl.store.access.conglomerate.GenericConglomerateController.replace(GenericConglomerateController.java:465)
>>        at org.apache.derby.impl.sql.execute.RowChangerImpl.updateRow(RowChangerImpl.java:516)
>>        at org.apache.derby.impl.sql.execute.UpdateResultSet.collectAffectedRows(UpdateResultSet.java:577)
>>        at org.apache.derby.impl.sql.execute.UpdateResultSet.open(UpdateResultSet.java:276)
>>        at org.apache.derby.impl.sql.GenericPreparedStatement.execute(GenericPreparedStatement.java:368)
>>        at org.apache.derby.impl.jdbc.EmbedResultSet.updateRow(EmbedResultSet.java:3256)

>>It fails when checking if the row has been deleted (not purged) , because pos.current_page
is null:
>>        if (pos.current_page.isDeletedAtSlot(pos.current_slot))
>>        {
>>            ret_val = false;
>>        }
>>The proposed fix is to use the return value from open_conglom.latchPage(..).  If it
returns false, the RowLocation is invalid (deleted+purged). 

View raw message