[ https://forge.continuent.org/jira/browse/SEQUOIA-1034?page=comments#action_14271 ]
Emmanuel Cecchet commented on SEQUOIA-1034: ------------------------------------------- This is by design and does not only apply to auto-incremented columns. This is why there is an enforceTableLocking option in the WaitForCompletion policy. enforceTableLocking should be set to true to solve that issue. Note that in the documented example, setting the transaction isolation level to serializable should also solve the issue since the database should properly lock the column for autoincremented keys. Unfortunately this is not the case with MySQL. I am not sure how PostgreSQL locks its sequences but that would be interesting to test. A fix only for auto-incremented keys seems futile since the same issue can easily be reproduced using subselects (which is another way of generating autoincremented keys). I would solve the issue by clarifying the enforceTableLocking option and adding this use case. > Possible race condition leading to concurrent requests being executed in a > different order on backends > ------------------------------------------------------------------------------------------------------ > > Key: SEQUOIA-1034 > URL: https://forge.continuent.org/jira/browse/SEQUOIA-1034 > Project: Sequoia > Type: Bug > Components: Core > Versions: Sequoia 2.10.9 > Reporter: Stephane Giron > Assignee: Stephane Giron > Priority: Critical > Fix For: sequoia 2.10.10 > > > This can lead to backends inconsistencies. > As an example, this is the behavior that was observed : > CREATE TABLE `table1` ( > `db_id` bigint(20) NOT NULL auto_increment, > `col1` varchar(255) default NULL, > `creation_date` datetime default NULL, > `request_date` varchar(255) default NULL, > `col2` varchar(255) default NULL, > `version` varchar(255) default NULL, > PRIMARY KEY (`db_id`), > UNIQUE KEY `col1` (`col1`,`col2`) > ) ENGINE=InnoDB DEFAULT CHARSET=latin1; > Transaction 1 > begin > insert into table1 (version) values('a1'); > insert into table1 (version) values('c1'); > commit > Transaction 2 > begin > insert into table1 (version) values('b') > commit > T1 begin > T2 begin > T1 insert 1 > T2 insert 1 > T1 insert 2 > commits > The following result is what I got in the backends : > On one controller : > | 8 | NULL | NULL | NULL | NULL | a1 | > | 9 | NULL | NULL | NULL | NULL | c1 | > | 10 | NULL | NULL | NULL | NULL | b | > On the other : > | 8 | NULL | NULL | NULL | NULL | a1 | > | 9 | NULL | NULL | NULL | NULL | b | > | 10 | NULL | NULL | NULL | NULL | c1 | > This can happen if the statement "T2 insert 1", which will be posted in the > conflicting queue, can be processed on one controller (because there is > nothing else at this time in the non conflicting queue), whereas on the other > controller the "T1 insert 2" statement arrives in the non conflicting queue > before "T2 insert 1" starts executing. > This behavior can be observed essentially because of the auto incremented > key. However other type of statements may run out of order as well. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://forge.continuent.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira _______________________________________________ Sequoia mailing list [email protected] https://forge.continuent.org/mailman/listinfo/sequoia
