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