PDOException: SQLSTATE[40001]: Serialization failure: 1213 Deadlock found

The same issue here. Use case - then big amount of the document with attachments are created automatically (e.g. during migration or synchronization). My case: 800+ documents, all with PDF attached, indexed as a part of parent node using #561862: Search results: possible to return node and not attachment? (patch https://drupal.org/node/561862#comment-6365870), synchronized from external system by cron using Drupal queue.

Looking into the code the main problem in clean up function "apachesolr_attachments_clean_index_table" that is executed on both entity update, insert and delete.

Possible solutions - move clean all entries where parent_entity_id is empty to hook_cron instead of hook_entity_update etc. What do you think?

function apachesolr_attachments_clean_index_table() {
  $indexer_table = apachesolr_get_indexer_table('file');
  // Clean all entries where parent_entity_id is empty
  db_delete($indexer_table)
  ->condition('parent_entity_id', 0)
  ->execute();
  // Clean all entries from entity types that should not be indexed
  foreach (entity_get_info() as $entity_type => $entity_info) {
    if (empty($entity_info['apachesolr']['indexable'])) {
       db_delete($indexer_table)
      ->condition('parent_entity_type', $entity_type)
      ->execute();
    }
  }
}

See patch attached.

So you want to move this to cron, maybe that makes sense but you should in your patch also remove all references to those calls

Hi, Nick.
I've grepped the module looking for further references to apachesolr_attachments_clean_index_table() and found none else.
Can you explain so I can reroll a new patch?

Hi Guys,

I'm having the same issue. The patch in #2 makes sense to me. As for #6, the only two places that are using the apachesolr_attachments_clean_index_table() function are apachesolr_attachments_entity_update and apachesolr_attachments_entity_delete, which have been removed in the patch.

I don't see any other references either; however, moving all that code around and deleting the function looks like an unnecessary API change?

Here's a simpler patch that leaves the API function in place, but just makes sure that hook_cron() is the only place that calls it.

Hi,

I have applied the #9 patch. But I just found, when attachment cron is running, at the same time if I tried to save a node, I got this error:

PDOException: SQLSTATE[40001]: Serialization failure: 1213 Deadlock found when trying to get lock; try restarting transaction: UPDATE {apachesolr_index_entities_file} SET bundle=:db_update_placeholder_0, status=:db_update_placeholder_1, changed=:db_update_placeholder_2 WHERE ( (entity_type = :db_condition_placeholder_0) AND (entity_id = :db_condition_placeholder_1) AND (parent_entity_type = :db_condition_placeholder_2) AND (parent_entity_id = :db_condition_placeholder_3) ); Array ( [:db_update_placeholder_0] => document [:db_update_placeholder_1] => 1 [:db_update_placeholder_2] => 1413152147 [:db_condition_placeholder_0] => file [:db_condition_placeholder_1] => 6228 [:db_condition_placeholder_2] => node [:db_condition_placeholder_3] => 16250 ) in apachesolr_attachments_add_file_usage() (line 220 of /app/sites/all/modules/contrib/apachesolr_attachments/apachesolr_attachments.index.inc).

That means I can only make attachment cron run when no one is editing node.

• Can anyone else confirm that #9 works as expected?
• Does the cron run collide with node saving as andrew-drupal reported in #10?
• Because index cleaning doesn't happen immediately now, is it possible for improper content to be visible in search results?

Maybe this help you: https://www.drupal.org/node/1936662#comment-9653553. We change the mysql table for apachesolr attachments body to a cache bin (Mongo in our case, but you can choose file cache or the bin you want...) and we are not sure that solve the deadlocks, but sure that helps.

Regards.

I am getting the same error while editing the Billing profile in Drupal commerce. I was creating different fields on billing profile and it gives me this error when i try to create a field.

PDOException: SQLSTATE[40001]: Serialization failure: 1213 Deadlock found when trying to get lock; try restarting transaction: DELETE FROM {semaphore} WHERE (name = :db_condition_placeholder_0) AND (value = :db_condition_placeholder_1) ; Array ( [:db_condition_placeholder_0] => field_info:fields [:db_condition_placeholder_1] => 14668081505548f5af485d86.04100930 ) in lock_release() (line 254 of /home/rashidkh/public_html/business/includes/lock.inc).

I don't this this is just related to Apache solr. Does anyone have any view about it?

Attaching an alternate patch which moves the cleanup to a shutdown function rather than into cron.

Update to patch from #14 as function was registering and running multiple times instead of just once on shutdown.

Uploaded wrong file for comment 15, correcting

I tried #9 and #16 and both worked for me.

There's a request to make apachesolr_attachments_clean_index_table only run for entities that have attachments that is a possible duplicate.

apachesolr_attachments_clean_index_table() doesn't do anything that is specific to a given entity. All it does are maintenance queries, always the same.

Therefore I think it makes more sense to move it to hook_cron() instead of running it every time one saves an entity. It eliminates deadlocks (since there will be only 1 cron process) and it avoids executing too many DELETE queries (with a condition on a column which isn't indexed..). When you have a lot of data or a lot of entity types (messages, field_collections, og_memberships, etc), it really makes a big difference.

#16 worked for me. Thank you, tekante.

Since there are now two competing approaches in #9 and #16, could the maintainers chime in and make a decision?

Could anyone elaborate on the consequences of having potentially stale index entries (as may be the case with #9 if I'm not mistaken)? Otherwise I'd opt for #9.

Making patch #9 visible again.

Did a decision ever get taken on the way to go with this? I am regularly encountering this issue and its making the module unusable.

I've been coming up against this issue and have created a patch for running a quick select to see whether the (longer, slower) delete has to happen at all - in a lot of cases, it's unnecessary to even run db_delete. I think this is compatible with the cron-based solution as well.