1b0f0cddd6
* In order to avoid duplicates of same 'join' tasks we now use named locks to exclusively create a task execution for 'join' tasks in DB. Transaction that does that is always separate from task completion logic and is very short. This is needed to eliminate DB contention on same records of task execution table. This is also a reason to use a separate mechanism such as named locks, and additionally this reduces a number possible scenarios for getting into deadlocks because for task executions we have too many different access patterns that can lead to them in case of doing locking on right on their table records. So this approach guarantees that there's only one transaction creates a new task execution object for 'join' task and schedules 'refresh_task_state' job that check 'join' completion. * Dropped scheduler 'unique_key' column with unique constraint because in practice it causes DB deadlocks (at least on MySQL) while simultaneously inserting and updating the table * Instead of 'unique_key' column we added non-unique 'key' column that can potentially be used for squashing delayed calls by scheduler itself (not implemented yet) * Adjusted Scheduler implementation and tests accordingly * Fixed task() YAQL function to work without precisely resolve task execution object in case it's called for the current task. Previously it was dependent on the luck and we were lucky enough that tests were passing. * Increased length of 'unique_key' column for task executions to 250 which is close to a limit for string fields participating in unique constraints. Change-Id: Ib7aaa20c2c8834ab0f2d9c90457677c9edb62805 |
||
---|---|---|
.. | ||
actions | ||
api | ||
cmd | ||
db | ||
engine | ||
hacking | ||
resources | ||
services | ||
tests | ||
utils | ||
workbook | ||
workflow | ||
__init__.py | ||
config.py | ||
context.py | ||
coordination.py | ||
exceptions.py | ||
expressions.py | ||
messaging.py | ||
version.py |