[jira] [Comment Edited] (DERBY-6977) Autogenerated index name occasionally generates a name which already exists

["Bryan Pendleton (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/DERBY-6977?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16248297#comment-16248297 ] 

Bryan Pendleton edited comment on DERBY-6977 at 11/11/17 4:02 AM:
------------------------------------------------------------------

Cool! So the problem arises if you create two different sequences within the same millisecond? Or tenth of a millisecond? Or hundredth? 

I read through your patch and it looks nice and clean to me. +1 to commit.

I guess that, once we generate the sequence name, it is just a string?

So, if we change the name generator, we have no upgrade issues?




was (Author: bryanpendleton):
Wow it's crazy that we never saw this before.

I read through your patch and it looks nice and clean to me. +1 to commit.

I guess that, once we generate the sequence name, it is just a string?

So, if we change the name generator, we have no upgrade issues?



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