SQL Lock wait timeout exceeded; try restarting transaction

[hartenthaler]

I just found several errors in my productive webtrees logfile from IP address 127.0.0.1:
SQLSTATE[HY000]: General error: 1205 Lock wait timeout exceeded; try restarting transaction (Connection: default, SQL: update wt_module_settingsetsetting_value = 0 where (module_name= _custom_module_manager_ andsetting_name= github_communication_error) limit 1) …/vendor/illuminate/database/Connection.php:824 #0 …/vendor/illuminate/database/Connection.php(778): Illuminate\Database\Connection-&gt;runQueryCallback() #1 …/vendor/illuminate/database/Connection.php(583): Illuminate\Database\Connection-&gt;run() #2 …/vendor/illuminate/database/Connection.php(535): Illuminate\Database\Connection-&gt;affectingStatement() #3 …/vendor/illuminate/database/Query/Builder.php(3917): Illuminate\Database\Connection-&gt;update() #4 …/vendor/illuminate/database/Query/Builder.php(3963): Illuminate\Database\Query\Builder-&gt;update() #5 …/app/Module/AbstractModule.php(187): Illuminate\Database\Query\Builder-&gt;updateOrInsert() <b>#6 …/modules_v4/custom_module_manager/src/CustomModuleManager.php(169): Fisharebest\Webtrees\Module\AbstractModule-&gt;setPreference()</b> #7 …/app/Services/ModuleService.php(889): Jefferson49\Webtrees\Module\CustomModuleManager\CustomModuleManager-&gt;boot() #8 …/app/Http/Middleware/BootModules.php(56): Fisharebest\Webtrees\Services\ModuleService-&gt;bootModules() #9 …/app/Http/Dispatcher.php(76): Fisharebest\Webtrees\Http\Middleware\BootModules-&gt;process() ...

[Jefferson49]

I searched in my webtrees logs, but could not find the same error.

The topic is obviously related to a preference value "github_communication_error", which I use in Custom Module Manager. The background is that I do not want to show too many flash messages if GitHub communication errors occur. Therefore, I remember the first occurance in the module preferences and do not show further flash messages for the 2nd, 3rd, ... communication errors.

With an internet search, I found an article, which seems to explain the MySQL background. I could imagine that the Custom Module Manager creates (too) many database requests for this specific preference value; or to the module preferences in general. Maybe, some other modules have write transactions on simular data. If there are too many parallel activities, the lock wait time might exceed.

I think I will ask Greg in the forum if this understanding is correct or if there are other aspects.

[Jefferson49]

Maybe, I could also consider to move the information from the module preferences to some other variable. It seems that persistency is not needed. I also recognized in the code that I reset the value during module bootstrap.