This error is not related to your problem before. We see such errors in every ILIAS Instance with high numbers of concurrent users.
In your special case it's caused by object statistics that is writing to your database in high frequency.
The error is caused by "race" conditions where running php-queries are being overtaken by others while constructing DB-Update statements. This happens more frequently in load-balanced clusters but it happens also on single nodes (Parallel running php-threads/processes). To completely get rid of such errors would be a a very hard workload for ALL ILIAS Developers and could be done only by building a really transactional database interface and using also MySQL/MariaDB's InnoDB transactional features to full extend to ensure atomic database updates, referential integrity and inclusion of COMMIT and ROLLBACK handling.
There is a first step feature wiki entry pending for at least referential integrity and work will be done in this direction in future for really important parts of the software. (See https://docu.ilias.de/goto.php?target=wiki_1357_Establish_Referential_Integrity and https://docu.ilias.de/goto.php?target=wiki_1357_Generalized_Management_Functions_for_Referential_Integrity)
For Test and Assessment there is a "locking" mechanism implemented to ensure integrity. You really should use "file based" locking to be able to serve large numbers of concurrent users in T&A. The default table locking is crap because every table access will be locked. So you really throw away the nice "row-based" locking of InnoDB by implementing application-based table locks.
If performance and high concurrency is very important you should also consider the value and cost of running with activated object statics....
For important T&A tasks a dedicated ILIAS instance without such "management blah blah" functions like object statistics and a whole bunch of useless plugins for this use case would be a good suggestion, too. In fact we have special purpose T&A Clusters in a few universities we support.
In your special case it's caused by object statistics that is writing to your database in high frequency.
The error is caused by "race" conditions where running php-queries are being overtaken by others while constructing DB-Update statements. This happens more frequently in load-balanced clusters but it happens also on single nodes (Parallel running php-threads/processes). To completely get rid of such errors would be a a very hard workload for ALL ILIAS Developers and could be done only by building a really transactional database interface and using also MySQL/MariaDB's InnoDB transactional features to full extend to ensure atomic database updates, referential integrity and inclusion of COMMIT and ROLLBACK handling.
There is a first step feature wiki entry pending for at least referential integrity and work will be done in this direction in future for really important parts of the software. (See https://docu.ilias.de/goto.php?target=wiki_1357_Establish_Referential_Integrity and https://docu.ilias.de/goto.php?target=wiki_1357_Generalized_Management_Functions_for_Referential_Integrity)
For Test and Assessment there is a "locking" mechanism implemented to ensure integrity. You really should use "file based" locking to be able to serve large numbers of concurrent users in T&A. The default table locking is crap because every table access will be locked. So you really throw away the nice "row-based" locking of InnoDB by implementing application-based table locks.
If performance and high concurrency is very important you should also consider the value and cost of running with activated object statics....
For important T&A tasks a dedicated ILIAS instance without such "management blah blah" functions like object statistics and a whole bunch of useless plugins for this use case would be a good suggestion, too. In fact we have special purpose T&A Clusters in a few universities we support.