In database it is giving below error from log.

[error]  Drupal\Core\Database\DatabaseExceptionWrapper: SQLSTATE[HY000]: General error: 1205 Lock wait timeout exceeded; try restarting transaction: DELETE FROM {autosave_form_entity_form}
WHERE (entity_type_id = :db_condition_placeholder_0) AND (entity_id = :db_condition_placeholder_1); Array
(
    [:db_condition_placeholder_0] => media
    [:db_condition_placeholder_1] => 716136
)
in autosave_form_entity_update() (line 112 of /..../modules/contrib/autosave_form/autosave_form.module).

Issue fork autosave_form-3029155

Command icon Show commands

Start within a Git clone of the project using the version control instructions.

Or, if you do not have SSH keys set up on git.drupalcode.org:

About issue forks

Comments

shahankitb created an issue. See original summary.

shahankitb’s picture

shahankitb commented
Issue summary: View changes
hchonov’s picture

hchonov
Primary language Bulgarian
Location Burgas
commented

I don't think that this issue is triggered by the autosave_form module. To me it looks like that it adds a little overhead and then you exceed your lock wait timeout.

What is the value of innodb_lock_wait_timeout of your database? How long does it take to save that particular entity (media, ID 716136) without having autosave_form enabled?

hchonov’s picture

hchonov
Primary language Bulgarian
Location Burgas
commented
Status: Needs work » Postponed (maintainer needs more info)

mediabounds made their first commit to this issue’s fork.

mediabounds opened merge request !7

mediabounds’s picture

mediabounds commented

We are periodically running into this issue to and I _believe_ it happens when many entities are being updated/deleted at about the same time.

Regardless of whether an entity has a form or has any entries in autosave_form_entity_form, when an entity changes, a call is made to AutosaveEntityFormStorageInterface::purgeAutosavedEntityState. The resulting query is going to look like:
DELETE FROM `autosave_form_entity_form` WHERE ( `entity_type_id` = ? ) AND ( `entity_id` = ? )

Since the PRIMARY index is not suitable for this, it results in the whole table having to be scanned (even if there are no matching records). So if there are many autosave entries or many subsequent entity updates, the row locks may start backing up and eventually time out.

Adding an index that covers entity_type_id and entity_id seems to cover this scenario.

mediabounds’s picture

mediabounds commented
Status: Postponed (maintainer needs more info) » Needs review
alexj12’s picture

alexj12 commented
Status: Needs review » Reviewed & tested by the community

Confirming that we ran into this issue recently and during an incident applied the same indexes which resolved the issue. The fact that the current PRIMARY index is composite means it isn't used in the troublesome query.

Reviewed and tested by the community!

alexj12’s picture

alexj12 commented

Link to the documentation outlining that the order of the columns in the index is important and the current PRIMARY index does not optimise the query.

  • hchonov committed ba123ddb on 8.x-1.x authored by mediabounds 
    Issue #3029155: General error: 1205 Lock wait timeout exceeded; try...
hchonov’s picture

hchonov
Primary language Bulgarian
Location Burgas
commented
Status: Reviewed & tested by the community » Fixed

Thank you. This will be part of the 1.6 release.

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.

rajeshreeputra’s picture

rajeshreeputra
he/him
Location Pune
commented

This introduced error on upgrade please see - #3497311: update hook autosave_form_update_8004 throws error