[ https://forge.continuent.org/jira/browse/SEQUOIA-1034?page=comments#action_14496 ]
Emmanuel Cecchet commented on SEQUOIA-1034: ------------------------------------------- I guess the ideal solution is to implement a distributed database engine which is not the purpose of Sequoia. Here are some comments: 1: This is wrong, users with MyIsam create deadlocks because they have to use the LOCK TABLE command that has a couple of nasty side effects (see deadlocks when fetching the schema bug in C-JDBC/Sequoia few years ago). And single statement transactions are fine too, they should never cause deadlocks. 3: if the application does not acquire its locks in the same order in different transactions, it will end-up in deadlocks even with a single database. So the problem seems to be more in the application rather than in Sequoia there. Another option is to modify the application to declare at begin time all the locks it needs (this is what is done in research prototypes using certification algorithms). 4.2. Rollback/Abort/Cancel of blocked transactions is usually at best not deterministic or not available at all depending on implementations. 4.4. This will require the ability to map queries in Sequoia with queries in the database which might not be trivial at all. Another solution consists of using the semantic information (currently ported to Sequoia 4). One can define its own set of locks (even purely logical ones) to order requests. The first request of the transaction could also hold all the locks of the transaction if we don't want the transaction to proceed without all the locks. This requires user effort and is not transparent (though some tools could automate the generation of that semantic info) Another idea I had was to really have middleware-level stored procedures where actually the transactions and lock-sets could be pre-compiled. The application would not have multi-statement transactions (which are the only issue actually, single statement transactions are fine) anymore, it would just call middleware stored procedures that would contain the transactions. > 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
