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-268) Add Support for truncate table
Date Mon, 27 Sep 2010 15:59:33 GMT

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

Rick Hillegas updated DERBY-268:
--------------------------------

    Attachment: TruncateConcurrency.java

Thanks, Knut. Your theory about the hang sounds good to me. Not sure about DERBY-979. I'm
seeing a different stack trace than what's recorded on that issue (see below). I do see the
same stack trace regardless of whether the truncating operation is TRUNCATE TABLE or DROP
TABLE. As you note, TRUNCATE TABLE is behaving like DROP TABLE, which makes some sense since
they are both implemented using the DDL machinery. Attaching a new rev of TruncateConcurrency.java.
This compares the behavior of TRUNCATE TABLE to DROP TABLE and DELETE FROM.


---------


Here's how to run the new rev of the program:

   java TruncateConcurrency $resetOperation $transaction $sensitivity [ $commit ]*

   where

   $resetOperation = truncate | drop | delete (whether the re-initialization operation should
be TRUNCATE TABLE, DROP TABLE, or DELETE
   $transaction  =    same | different (whether the reader and truncator do their work in
the same transaction)
   $sensitivity    =    sensitive | insensitive (whether the reader should use a sensitive
or insensitive cursor)
   $commit       =    commitSelector | commitTruncator

   If commitSelector is specified, then the Selector commits after
   reading a row but before the truncation.

   If commitTruncator is specified, then the Truncator commits
   immediately after truncation.

   E.g.:

   java TruncateConcurrency different sensitive commitTruncator commitSelector

-----------

As previously, I see the following behavior for TRUNCATE TABLE:

1) In the following experiments, the TRUNCATE TABLE raises "Operation 'TRUNCATE TABLE' cannot
be performed on object 'T' because there is an open ResultSet dependent on that object.":

java TruncateConcurrency truncate same sensitive
java TruncateConcurrency truncate same sensitive commitTruncator
java TruncateConcurrency truncate same sensitive commitSelector
java TruncateConcurrency truncate same sensitive commitTruncator commitSelector
java TruncateConcurrency truncate same insensitive
java TruncateConcurrency truncate same insensitive commitTruncator
java TruncateConcurrency truncate same insensitive commitSelector
java TruncateConcurrency truncate same insensitive commitTruncator commitSelector



2) When the Selector and Truncator are DIFFERENT transactions, then Derby misbehaves. There
are two kinds of misbehavior here. The sub-cases are distinguished by whether the Truncator
committed immediately after truncating the table. Whether the Selector committed after reading
its first row is also irrelevant.

2a) In the following experiments, the Selector triggers an NPE when calling ResultSet.next():

java TruncateConcurrency truncate different sensitive commitTruncator
java TruncateConcurrency truncate different sensitive commitTruncator commitSelector
java TruncateConcurrency truncate different insensitive commitTruncator
java TruncateConcurrency truncate different insensitive commitTruncator commitSelector

This is the NPE:

java.lang.NullPointerException
	at org.apache.derby.impl.store.access.conglomerate.GenericController.setEstimatedRowCount(GenericController.java:224)
	at org.apache.derby.impl.sql.execute.TableScanResultSet.setRowCountIfPossible(TableScanResultSet.java:1325)
	at org.apache.derby.impl.sql.execute.BulkTableScanResultSet.getNextRowCore(BulkTableScanResultSet.java:311)
	at org.apache.derby.impl.sql.execute.ScrollInsensitiveResultSet.getNextRowFromSource(ScrollInsensitiveResultSet.java:801)
	at org.apache.derby.impl.sql.execute.ScrollInsensitiveResultSet.getNextRowCore(ScrollInsensitiveResultSet.java:518)
	at org.apache.derby.impl.sql.execute.BasicNoPutResultSetImpl.getNextRow(BasicNoPutResultSetImpl.java:477)
	at org.apache.derby.impl.jdbc.EmbedResultSet.movePosition(EmbedResultSet.java:429)
	at org.apache.derby.impl.jdbc.EmbedResultSet.next(EmbedResultSet.java:373)
	at TruncateConcurrency.printRow(TruncateConcurrency.java:188)
	at TruncateConcurrency.justDoIt(TruncateConcurrency.java:97)
	at TruncateConcurrency.main(TruncateConcurrency.java:49)



2b) The following experiments hang the Selector when calling ResultSet.next():

java TruncateConcurrency truncate different sensitive
java TruncateConcurrency truncate different sensitive commitSelector
java TruncateConcurrency truncate different insensitive
java TruncateConcurrency truncate different insensitive commitSelector

-----------

I see the following behavior for DROP TABLE:

1') In the following experiments, the DROP TABLE raises "DROP TABLE' cannot be performed on
object 'T' because there is an open ResultSet dependent on that object.":

java TruncateConcurrency drop same sensitive
java TruncateConcurrency drop same sensitive commitTruncator
java TruncateConcurrency drop same sensitive commitSelector
java TruncateConcurrency drop same sensitive commitTruncator commitSelector
java TruncateConcurrency drop same insensitive
java TruncateConcurrency drop same insensitive commitTruncator
java TruncateConcurrency drop same insensitive commitSelector
java TruncateConcurrency drop same insensitive commitTruncator commitSelector


2') When the Selector and Truncator are DIFFERENT transactions, then Derby misbehaves. There
are two kinds of misbehavior here. The sub-cases are distinguished by whether the Truncator
committed immediately after truncating the table. Whether the Selector committed after reading
its first row is also irrelevant.

2a') In the following experiments, the Selector triggers an NPE when calling ResultSet.next():

java TruncateConcurrency drop different sensitive commitTruncator
java TruncateConcurrency drop different sensitive commitTruncator commitSelector
java TruncateConcurrency drop different insensitive commitTruncator
java TruncateConcurrency drop different insensitive commitTruncator commitSelector

This is the NPE:

java.lang.NullPointerException
	at org.apache.derby.impl.store.access.conglomerate.GenericController.setEstimatedRowCount(GenericController.java:224)
	at org.apache.derby.impl.sql.execute.TableScanResultSet.setRowCountIfPossible(TableScanResultSet.java:1325)
	at org.apache.derby.impl.sql.execute.BulkTableScanResultSet.getNextRowCore(BulkTableScanResultSet.java:311)
	at org.apache.derby.impl.sql.execute.ScrollInsensitiveResultSet.getNextRowFromSource(ScrollInsensitiveResultSet.java:801)
	at org.apache.derby.impl.sql.execute.ScrollInsensitiveResultSet.getNextRowCore(ScrollInsensitiveResultSet.java:518)
	at org.apache.derby.impl.sql.execute.BasicNoPutResultSetImpl.getNextRow(BasicNoPutResultSetImpl.java:477)
	at org.apache.derby.impl.jdbc.EmbedResultSet.movePosition(EmbedResultSet.java:429)
	at org.apache.derby.impl.jdbc.EmbedResultSet.next(EmbedResultSet.java:373)
	at TruncateConcurrency.printRow(TruncateConcurrency.java:188)
	at TruncateConcurrency.justDoIt(TruncateConcurrency.java:97)
	at TruncateConcurrency.main(TruncateConcurrency.java:49)



2b') The following experiments hang the Selector when calling ResultSet.next():

java TruncateConcurrency drop different sensitive
java TruncateConcurrency drop different sensitive commitSelector
java TruncateConcurrency drop different insensitive
java TruncateConcurrency drop different insensitive commitSelector



-----------

I see the following behavior for DELETE FROM: All of the test cases terminate without errors.
The Selector is able to read the second row regardless of the sensitivity of the cursor and
regardless of whether the read takes place in the same transaction as DELETE FROM.

java TruncateConcurrency delete same sensitive
java TruncateConcurrency delete same sensitive commitTruncator
java TruncateConcurrency delete same sensitive commitSelector
java TruncateConcurrency delete same sensitive commitTruncator commitSelector
java TruncateConcurrency delete same insensitive
java TruncateConcurrency delete same insensitive commitTruncator
java TruncateConcurrency delete same insensitive commitSelector
java TruncateConcurrency delete same insensitive commitTruncator commitSelector
java TruncateConcurrency delete different sensitive
java TruncateConcurrency delete different sensitive commitTruncator
java TruncateConcurrency delete different sensitive commitSelector
java TruncateConcurrency delete different sensitive commitTruncator commitSelector
java TruncateConcurrency delete different insensitive
java TruncateConcurrency delete different insensitive commitTruncator
java TruncateConcurrency delete different insensitive commitSelector
java TruncateConcurrency delete different insensitive commitTruncator commitSelector


> Add Support for truncate table
> ------------------------------
>
>                 Key: DERBY-268
>                 URL: https://issues.apache.org/jira/browse/DERBY-268
>             Project: Derby
>          Issue Type: Improvement
>          Components: SQL
>            Reporter: Lance Andersen
>            Assignee: Eranda Sooriyabandara
>            Priority: Minor
>         Attachments: derby-268-01-ab-enableForInsaneBuilds.diff, derby-268-02-aa-permsTest.diff,
Derby-268.diff, tests.diff, TruncateConcurrency.java, TruncateConcurrency.java
>
>
> Adding support for truncate table command will aid to portability

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