[
https://issues.apache.org/jira/browse/DERBY-6977?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16248332#comment-16248332
]
Trejkaz commented on DERBY-6977:
--------------------------------
It turns out if you create two sequences in the same DataDictionary instance,
that is safe because it's synchronising it, and doing some convoluted hacks to
avoid the same timestamp being used twice... But when we run migrations, the
database is opened for the migration, migrated, and then closed, and then the
next migration runs, and so forth, so it's a new instance each time.
So I think this error must have occurred when we ran two migrations in a row,
both of them created an autogenerated index, and both occurred within the same
10ms interval, with the constructor of DataDictionaryImpl creating the same
values for all the other stuff as well. This last bit probably explains why it
was so hard to reproduce for me.
But it turns out you can reproduce it in isolation by creating a new
DataDictionaryImpl and then getSystemSQLName, then creating a new
DataDictionaryImpl and calling it again, and repeating that until the two
instances happen to get the same ID, which for me happens almost immediately.
Using a UUID definitely seems like a good solution.
> Autogenerated index name occasionally generates a name which already exists
> ---------------------------------------------------------------------------
>
> Key: DERBY-6977
> URL: https://issues.apache.org/jira/browse/DERBY-6977
> Project: Derby
> Issue Type: Bug
> Affects Versions: 10.13.1.1
> Reporter: Trejkaz
> Attachments: derby-6977-01-aa-useUUID.diff
>
>
> This has been happening for as long as I can remember, but v10.13.1.1 is the
> version we're currently at and I still see builds fail at random due to this.
> In a migration, we execute this statement:
> {noformat}
> CREATE TABLE GuidMappingCache (
> guidhigh BIGINT NOT NULL,
> guidlow BIGINT NOT NULL,
> luceneid INTEGER NOT NULL,
> PRIMARY KEY (guidhigh, guidlow)
> )
> {noformat}
> This randomly fails with the following sort of error:
> {noformat}
> Caused by: java.sql.SQLException: Index 'SQL171110050418720' already exists
> in Schema 'APP'.
> at
> org.apache.derby.impl.jdbc.SQLExceptionFactory.getSQLException(Unknown Source)
> at org.apache.derby.impl.jdbc.Util.generateCsSQLException(Unknown
> Source)
> at
> org.apache.derby.impl.jdbc.TransactionResourceImpl.wrapInSQLException(Unknown
> Source)
> at
> org.apache.derby.impl.jdbc.TransactionResourceImpl.handleException(Unknown
> Source)
> at org.apache.derby.impl.jdbc.EmbedConnection.handleException(Unknown
> Source)
> at org.apache.derby.impl.jdbc.ConnectionChild.handleException(Unknown
> Source)
> at org.apache.derby.impl.jdbc.EmbedStatement.executeStatement(Unknown
> Source)
> at org.apache.derby.impl.jdbc.EmbedStatement.execute(Unknown Source)
> at org.apache.derby.impl.jdbc.EmbedStatement.execute(Unknown Source)
> at OurCode.execute(...)
> Caused by: ERROR X0Y32: Index 'SQL171110050418720' already exists in Schema
> 'APP'.
> at org.apache.derby.iapi.error.StandardException.newException(Unknown
> Source)
> at org.apache.derby.iapi.error.StandardException.newException(Unknown
> Source)
> at
> org.apache.derby.impl.sql.catalog.DataDictionaryImpl.duplicateDescriptorException(Unknown
> Source)
> at
> org.apache.derby.impl.sql.catalog.DataDictionaryImpl.addDescriptor(Unknown
> Source)
> at
> org.apache.derby.impl.sql.execute.CreateIndexConstantAction.executeConstantAction(Unknown
> Source)
> at
> org.apache.derby.impl.sql.execute.CreateConstraintConstantAction.executeConstantAction(Unknown
> Source)
> at
> org.apache.derby.impl.sql.execute.CreateTableConstantAction.executeConstantAction(Unknown
> Source)
> at org.apache.derby.impl.sql.execute.MiscResultSet.open(Unknown Source)
> at
> org.apache.derby.impl.sql.GenericPreparedStatement.executeStmt(Unknown Source)
> at org.apache.derby.impl.sql.GenericPreparedStatement.execute(Unknown
> Source)
> ... 37 more
> {noformat}
> The last time someone was looking into this, it was somehow very reproducible
> for them but not for anyone else. I'm now seeing it occasionally on tests on
> our build farm. As usual, no matter how many times I run the test here, I
> can't get the same failure to occur.
> How is this value being generated?
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
