[ https://forge.continuent.org/jira/browse/SEQUOIA-739?page=all ] Emmanuel Cecchet closed SEQUOIA-739: ------------------------------------
Fixed version updated > Recovery plays requests in parallel that were not executed in parallel > originally, resulting in duplicate key violation > ----------------------------------------------------------------------------------------------------------------------- > > Key: SEQUOIA-739 > URL: https://forge.continuent.org/jira/browse/SEQUOIA-739 > Project: Sequoia > Type: Bug > Components: Core > Versions: Sequoia 2.10 > Environment: Customer M > Reporter: Edward Archibald > Assignee: Emmanuel Cecchet > Priority: Blocker > Fix For: Sequoia 3.0 beta 2 > > > The customer's application has a stored procedure that does the following (in > pseudo code) > create procedure insert_exception(@user_id int, @exception_id int, > @exception_text varchar(255)) > { > if (exists select * from exceptions where user_id = @user_id) > { > delete from exceptions where user_id = @user_id > } > insert into exceptions (user_id, exception_id, exception_text) > values (@user_id, @exception_id, @exception_text) > } > This procedure also is marked as 'isCommutative=true' at runtime. > When recovery occurs, it happened that recovery played this same procedure in > parallel in multiple worker threads with the effect being : > workerThread1 and workerThread2 both executed the initial 'select' statement > at nearly the same time or, at least, before the insert could occur. In this > case, the table was empty, so both thread proceeded to do the insert at which > time the second thread that attempted the insert got the duplicate key > exception. > An attempt was made to work around this issue by setting up the stored > procedure semantics such that non of the stored procedures were marked with > 'isCommutative=true' and this had the effect of: > - significantly impacting the performance of the system, causing many > timeouts on the client side > - causing a deadlock to be detected in an application where deadlocks NEVER > occur when run against the database directly. > So, at present, there is no good solution to this problem and Sequoia is > currently unusable by the customer. -- 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
