Bug #72553 Concurrency control is not locking the right objects

• Submitted: 6 May 2014 15:00
• Modified: 23 May 2014 3:50
• Reporter: Alfranio Tavares Correia Junior
• Status: Closed
• Category: MySQL Fabric
• Severity: S3 (Non-critical)
• Version: 1.4.0
• OS: Any
• Assigned to: Alfranio Tavares Correia Junior
• CPU Architecture: Any

[6 May 2014 15:00] Alfranio Tavares Correia Junior

Description:
A procedure in Fabric is scheduled according to the set of objects that are provided to the scheduler by the procedure itself when it is about to start. These objects are called lockable objects and are the group identifiers.

This means that update operations on the same group are serialized.

In order to ease the developer's life, the current implementation tries to automatically find out the lockable objects for a given procedure by analyzing the procedure's input parameters. Although this solution seems fine, it is really hard to keep it updated.

Due to the several changes in the high-availability and sharding sub-systems, this automatic routine is no longer valid. The consequence is that there may be procedures trying to update the same group concurrently when they should be serialized.

How to repeat:
Check the code in lib/mysql/fabric/command.py::Procedure::get_lockable_objects().

Suggested fix:
Change the get_lockable_objects method to return the appropriate objects.

Note that the current solution is not only hard to maintain but it also requires some non-trivial python mechanisms. We should also try to improve this in the future.

[23 May 2014 3:50] Philip Olson

Fixed as of the upcoming MySQL Utilities 1.4.3 release, and here's the changelog entry:

Due to the several changes in the high-availability and sharding
sub-systems, the automatic routine to automatically find the lockable
objects for a given procedure was not always valid. The consequence was
that some procedures may have tried to update the same group concurrently
when they should have been serialized.

Thank you for the bug report.