You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-dev@db.apache.org by "Mike Matrigali (JIRA)" <de...@db.apache.org> on 2006/04/12 01:30:25 UTC
[jira] Updated: (DERBY-979) NullPointerException in store when
using holdable resultset to get next tuple on a deleted table
[ http://issues.apache.org/jira/browse/DERBY-979?page=all ]
Mike Matrigali updated DERBY-979:
---------------------------------
Component: Store
> NullPointerException in store when using holdable resultset to get next tuple on a deleted table
> ------------------------------------------------------------------------------------------------
>
> Key: DERBY-979
> URL: http://issues.apache.org/jira/browse/DERBY-979
> Project: Derby
> Type: Bug
> Components: Store
> Environment: All
> Reporter: Andreas Korneliussen
> Priority: Minor
>
> 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.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira