db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Trejkaz (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (DERBY-6977) Autogenerated index name occasionally generates a name which already exists
Date Sat, 11 Nov 2017 05:07:00 GMT

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

Mime
View raw message