[ https://forge.continuent.org/jira/browse/SEQUOIA-739?page=all ]
Emmanuel Cecchet resolved SEQUOIA-739:
--------------------------------------
Resolution: Fixed
Fix Version: (was: Sequoia 3.0)
Sequoia 3.0 beta 2
Fixed
> 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
