[
https://issues.apache.org/jira/browse/DERBY-5367?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13113232#comment-13113232
]
Kristian Waagan commented on DERBY-5367:
----------------------------------------
Tests ran cleanly on 10.8 (with the fixed merged from trunk), with the
exception of this error in
testConcurrentInvalidation(org.apache.derbyTesting.functionTests.tests.lang.TruncateTableTest):
Helper thread failed
...
Fri Sep 23 01:19:36 CEST 2011 Thread[DRDAConnThread_77,5,derby.daemons] (XID =
24553), (SESSIONID = 31), (DATABASE = dbsqlauth), (DRDAID =
��������.��-808957766332849398{3}), Failed Statement is: select * from d4275
ERROR XSAI2: The conglomerate (4,448) requested does not exist.
at
org.apache.derby.iapi.error.StandardException.newException(StandardException.java:286)
at
org.apache.derby.impl.store.access.heap.HeapConglomerateFactory.readConglomerate(HeapConglomerateFactory.java:254)
at
org.apache.derby.impl.store.access.RAMAccessManager.conglomCacheFind(RAMAccessManager.java:482)
at
org.apache.derby.impl.store.access.RAMTransaction.findExistingConglomerate(RAMTransaction.java:394)
at
org.apache.derby.impl.store.access.RAMTransaction.getDynamicCompiledConglomInfo(RAMTransaction.java:692)
at
org.apache.derby.impl.sql.execute.TableScanResultSet.openCore(TableScanResultSet.java:245)
at
org.apache.derby.impl.sql.execute.BulkTableScanResultSet.openCore(BulkTableScanResultSet.java:248)
at
org.apache.derby.impl.sql.execute.BasicNoPutResultSetImpl.open(BasicNoPutResultSetImpl.java:255)
at
org.apache.derby.impl.sql.GenericPreparedStatement.executeStmt(GenericPreparedStatement.java:436)
at
org.apache.derby.impl.sql.GenericPreparedStatement.execute(GenericPreparedStatement.java:317)
at
org.apache.derby.impl.jdbc.EmbedStatement.executeStatement(EmbedStatement.java:1242)
at
org.apache.derby.impl.jdbc.EmbedPreparedStatement.executeStatement(EmbedPreparedStatement.java:1686)
at
org.apache.derby.impl.jdbc.EmbedPreparedStatement.execute(EmbedPreparedStatement.java:1341)
at
org.apache.derby.impl.drda.DRDAStatement.execute(DRDAStatement.java:706)
at
org.apache.derby.impl.drda.DRDAConnThread.processCommands(DRDAConnThread.java:866)
at
org.apache.derby.impl.drda.DRDAConnThread.run(DRDAConnThread.java:295)
Cleanup action completed
I plan to backport the fix on Saturday.
> Stale data retrieved when using new collation=TERRITORY_BASED:PRIMARY feature
> -----------------------------------------------------------------------------
>
> Key: DERBY-5367
> URL: https://issues.apache.org/jira/browse/DERBY-5367
> Project: Derby
> Issue Type: Bug
> Components: Store
> Affects Versions: 10.8.1.2, 10.9.0.0
> Environment: Mac OS X, Windows
> Reporter: Brett Wooldridge
> Assignee: Kristian Waagan
> Priority: Critical
> Fix For: 10.9.0.0
>
> Attachments: derby-5367-1a-update_row_fully.diff,
> derby-5367-1b-update_row_fully.diff, derby-5367-1b-update_row_fully.stat,
> derby-5367-2a-minimal_fix.diff,
> derby-5367-3a-update_field_by_field_preview.diff,
> derby-5367-4a-fix_with_optimization_improved.diff,
> derby-5367-4b-fix_with_optimization_improved.diff,
> derby-5367-4c-fix_with_optimization_improved.diff
>
>
> Our product recently upgraded to version 10.8.1.2 in order to take advantage
> of the new 'case-insensitive' mode offered by Derby in the form of the
> "collation=TERRITORY_BASED:PRIMARY" connection parameter.
> Unfortunately, we have run into an issue whereby stale data appears to be
> retrieved from an index, even though the data in the table itself has changed.
> You can see this issue in the IJ session below. The database in question was
> created using this Java parameter when invoking IJ:
> -Dij.database=jdbc:derby:test;create=true;collation=TERRITORY_BASED:PRIMARY
> Here is the IJ session:
> CONNECTION0* - jdbc:derby:test
> * = current connection
> ij> CREATE TABLE tag (
> tag_id INTEGER GENERATED BY DEFAULT AS IDENTITY NOT NULL,
> tag VARCHAR(255) NOT NULL,
> CONSTRAINT tag_pk PRIMARY KEY (tag_id),
> CONSTRAINT tag_tag_unique UNIQUE (tag)
> );
> 0 rows inserted/updated/deleted
> ij> -- first insert a value 'Test', note the upper-case 'T' in 'Test'
> ij> INSERT INTO tag (tag) VALUES ('Test');
> 1 row inserted/updated/deleted
> ij> SELECT * FROM tag;
> TAG_ID |TAG
>
> --------------------------------------------------------------------------------------------------------------------------------------------
> 1 |Test
>
> 1 row selected
> ij> -- Now delete the row
> ij> DELETE FROM tag WHERE tag='Test';
> 1 row inserted/updated/deleted
> ij> -- You could run another SELECT here to verify it is gone, but it is.
> ij> -- Now insert a new value 'test', note the lower-case 't' in 'test'
> ij> INSERT INTO tag (tag) VALUES ('test');
> 1 row inserted/updated/deleted
> ij> -- Now verify that the table contains only the lower-case version: 'test'
> ij> SELECT * FROM tag;
> TAG_ID |TAG
>
> --------------------------------------------------------------------------------------------------------------------------------------------
> 2 |test
>
> 1 row selected
> ij> -- Now, here is the bug.
> ij> SELECT tag FROM tag;
> TAG
>
> --------------------------------------------------------------------------------------------------------------------------------
> Test
>
> 1 row selected
> ij>
> Note in the last SELECT we specify the 'tag' column specifically. When we
> 'SELECT *', Derby performs a table-scan and the result is correct. However,
> when we 'SELECT tag', Derby appears to use the index created for the
> 'tag_tag_unique' unique constraint. As an optimization Derby, like many
> databases, will use values directly from the index in the case where the
> index covers all requested columns.
> The bigger question is, why doesn't the DELETE action cause the entry in the
> tag_tag_unique index to be deleted? Is this a further optimization? If so,
> it is imperative that the index at least be updated when the new value is
> inserted.
> This is rather a severe bug for us that causes stale data to be returned.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
