Details
-
Bug
-
Resolution: Duplicate
-
None
-
None
-
Critical
-
Worker locking is not working completely and corresponding indices are inefficient
-
Empty show more show less
Description
problem
In a client instance a task import failed with error message
ERROR in core.entity.editor_Models_Foldertree.editor_Models_Foldertree: E1015 - Duplicate Key on saving editor_Models_Foldertree
triggered by
SQLSTATE[23000]: Integrity constraint violation: 1062 Duplicate entry '{d605dcc3-0d1f-45b8-8b2b-8d957bcd1c16}' for key 'taskGuid', query was: INSERT INTO `LEK_foldertree` (`tree`, `taskGuid`) VALUES (?, ?)
reason
The reason was, that the worker which produces the folder tree was started twice.
In the most cases this is prevented by worker->isMutexAccess check, but after investigation it came out, that this check is incomplete, since the locking done by the underlying method is not atomic. In isMutexAccess the state and the hash of the worker is checked but only the hash is updated there. The state is set some lines of code later to state running. If a second request tries to start the same worker between isMutexAccess call and setRunning this error can happen.
solution
Evaluate if we can directly set the worker to running in isMutexAccess, but the state must then be rolled back on failure.
additional todos
The indices of the worker table must be optimized to the performed requests, currently there is one index per field.
Also "SET TRANSACTION ISOLATION LEVEL READ COMMITTED" should be added to the ismutexaccess function and to the scheduleprepared call.
Attachments
Issue Links
- is cloned by
-
TRANSLATE-2500 Worker Architecture: Solving Problems with Deadlocks and related Locking/Mutex Quirks
- Done
- relates to
-
TRANSLATE-1673 Parallele import of several large import packages produces deadlock
- Done