db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rick Hillegas (JIRA)" <j...@apache.org>
Subject [jira] Updated: (DERBY-979) NullPointerException in store when using holdable resultset to get next tuple on a deleted table
Date Tue, 28 Sep 2010 19:22:33 GMT

     [ https://issues.apache.org/jira/browse/DERBY-979?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Rick Hillegas updated DERBY-979:
--------------------------------

    Attachment: testCase.diff

Attaching testCase.diff. This patch rewarms the test case supplied in the comment above. With
this patch, ConcurrencyTest still raises an NPE, although the NPE has moved. The new NPE is:

Caused by: java.lang.NullPointerException
	at org.apache.derby.impl.store.access.conglomerate.GenericScanController.reopenAfterEndTransaction(GenericScanController.java:1041)
	at org.apache.derby.impl.store.access.conglomerate.GenericScanController.fetchRows(GenericScanController.java:604)
	at org.apache.derby.impl.store.access.heap.HeapScan.fetchNext(HeapScan.java:238)
	at org.apache.derby.impl.sql.execute.TableScanResultSet.getNextRowCore(TableScanResultSet.java:577)
	at org.apache.derby.impl.sql.execute.BasicNoPutResultSetImpl.getNextRow(BasicNoPutResultSetImpl.java:477)
	at org.apache.derby.impl.jdbc.EmbedResultSet.movePosition(EmbedResultSet.java:429)


> NullPointerException in store when using holdable resultset to get next tuple on a deleted
table
> ------------------------------------------------------------------------------------------------
>
>                 Key: DERBY-979
>                 URL: https://issues.apache.org/jira/browse/DERBY-979
>             Project: Derby
>          Issue Type: Bug
>          Components: Store
>         Environment: All
>            Reporter: Andreas Korneliussen
>            Priority: Minor
>         Attachments: testCase.diff
>
>
> Derby uses table intent locks to prevent a table from being dropped while there is an
open cursor on it.
> However, for holdable cursors, the lock is released after the commit. This allows a drop
table command to drop the table.  The next call to ResultSet.next then get a NullPointerException
from the store module.
> A potential fix, could be to handle this situation in store, and to give a meaningful
error message.
> Transaction history:
> T1: select * from table1 
> T1: cursor.next()
> T1: commit
> T2: drop table table1
> T2: commit
> T3: cursor.next()..
> Result: T3 get NullPointerException.
> To reproduce: Add the following testcase to ConcurrencyTest.java (see DERBY-934) (hopefully
someone commits those tests soon)
>   /**
>      * Test that as long as an cursor is open on a table, no
>      * other transaction can delete the table.
>      */
>     public void testTableIntentLockWithHoldableCursor() 
>         throws SQLException
>     {
>         con.setTransactionIsolation(Connection.TRANSACTION_READ_UNCOMMITTED);
>         con.setAutoCommit(true); 
>         Statement s = con.createStatement(ResultSet.TYPE_FORWARD_ONLY, 
>                                           ResultSet.CONCUR_UPDATABLE);
>         ResultSet rs = s.executeQuery("select * from t1");
>         rs.next();
>         updateTuple(rs);
>         con.commit();
>         
>         Connection con2 = getNewConnection();
>         con2.setTransactionIsolation(Connection.TRANSACTION_READ_COMMITTED);
>         
>         try {
>             PreparedStatement ps2 = con2.prepareStatement
>                 ("drop table t1");
>             ps2.executeUpdate();
>             con2.commit();
>                         
>             // .. WHAT happens ?
>             rs.next();
>             updateTuple(rs);
>         } catch (SQLException e) {
>             System.out.println(e.getMessage() + ":" + e.getSQLState());
>             printStackTrace(e);
>             assertEquals("Unexpected SQL state",  LOCK_TIMEOUT_SQL_STATE,
>                          e.getSQLState());
>         } finally {
>             con2.close();
>         }          
>     }
> java.lang.NullPointerException
>         at org.apache.derby.impl.store.access.conglomerate.OpenConglomerate.latchPageAndRepositionScan(OpenConglomerate.java:264)
>         at org.apache.derby.impl.store.access.conglomerate.GenericScanController.fetchRows(GenericScanController.java:613)
>         at org.apache.derby.impl.store.access.heap.HeapScan.fetchNext(HeapScan.java:207)
>         at org.apache.derby.impl.sql.execute.TableScanResultSet.getNextRowCore(TableScanResultSet.java:681)
>         at org.apache.derby.impl.sql.execute.BasicNoPutResultSetImpl.getNextRow(BasicNoPutResultSetImpl.java:474)
>         at org.apache.derby.impl.jdbc.EmbedResultSet.movePosition(EmbedResultSet.java:371)
>         at org.apache.derby.impl.jdbc.EmbedResultSet.next(EmbedResultSet.java:320)
>         at org.apache.derbyTesting.functionTests.tests.jdbcapi.ConcurrencyTest.testTableIntentLockWithHoldableCursor(ConcurrencyTest.java:877)
> ..
> The NullPointerException is wrapped in a SQLException, which just makes the bug more
confusing for the user.

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