Взаимоблокировки Magento

Я столкнулся с этой проблемой, когда пытался импортировать более пяти или шести продуктов одновременно. Дополнительную информацию о взаимоблокировках можно найти здесь< /а>.

Чтобы решить эту проблему, мне пришлось разместить запросы к базе данных в SERIALIZABLE. транзакций, где это возможно, например:

$adapter = Mage::getModel('core/resource')->getConnection('core_write');
// Commit any existing transactions (use with caution!)
if ($adapter->getTransactionLevel > 0) {
    $adapter->commit();
}
$adapter->query('SET TRANSACTION ISOLATION LEVEL SERIALIZABLE');
$product->save(); // etc

Пример транзакции:

$adapter = Mage::getModel('core/resource')->getConnection('core_write');
// Commit any existing transactions (use with caution!)
if ($adapter->getTransactionLevel > 0) {
    $adapter->commit();
}
$adapter->query('SET TRANSACTION ISOLATION LEVEL SERIALIZABLE');
$adapter->beginTransaction();
try {
    $adapter->query(/* SQL goes here */);
    $adapter->commit();
} catch (Exception $e) {
    // Rollback on fail always
    $adapter->rollBack();
    throw $e;
}

Если вам потребуется дополнительная помощь в этом, не стесняйтесь, дайте мне знать.

У нас была аналогичная проблема с появлением взаимоблокировок несколько раз в день, когда клиенты пытались что-то добавить в свою корзину. Наши тоже, похоже, были связаны с обновляемым в то время индексом (скорее всего, с переиндексацией таблицы каталога). Единственное, что, наконец, решило проблему для нас, — это реализовать асинхронную переиндексацию (в итоге мы купили расширение).

мы столкнулись с этой проблемой, пытаясь сохранить продукты параллельно.

основная проблема, с которой мы столкнулись, заключалась в том, что после первоначального сохранения продукта последующие процессы индексации не охватывались транзакцией сохранения продукта. поэтому всякий раз, когда мы сталкивались с тупиковой ситуацией, она была вызвана индексатором, и в довершение всего у нас была несогласованная база данных, которая приводила к недопустимым URL-адресам продукта и вынуждала нас переиндексировать все каждый раз, когда это происходило.

решение, к которому мы пришли, заключалось в том, чтобы включить индексатор в транзакцию и повторить транзакцию, которая оказалась в тупике. однако это не идеальное решение, это лучшее, что мы могли придумать, и оно работает в 99% случаев.

проблема с magento заключается в том, что программирование неаккуратно, а подход швейцарского армейского ножа, основанный на событиях, приводит к множеству серьезных проблем во внутренней механике magento.

нашим следующим подходом будет наш собственный интерфейс, написанный с нуля, для параллельного сохранения продуктов и выхода из базы данных с тем же результатом, что и при сохранении magento. это, конечно, будет означать, что мы больше не сможем добавлять расширения, не интегрируя их в эту новую концепцию, если они связаны с продуктом.

Вот отличное решение с открытым исходным кодом — https://github.com/AOEpeople/Aoe_DbRetry.

Этот модуль очень прост и сосредоточен на одной задаче. Он заменяет адаптер БД расширенной версией, которая повторяет запросы, если соединение потеряно, запрос не может получить необходимую блокировку или возникает взаимоблокировка. Эти три ситуации обнаруживаются с помощью сообщений об исключениях. Базовый (родительский) код фактически заключает по крайней мере одно из этих исключений в другое исключение, поэтому мы проверяем это и при необходимости разворачиваем исключение.

Я переключаю режим индексирования на РУЧНОЙ перед импортом с помощью сценариев CRON.

$indexCollection = Mage::getSingleton('index/indexer')->getProcessesCollection(); 
foreach ($indexCollection as $process) {
    $process->setMode(Mage_Index_Model_Process::MODE_MANUAL)->save();
    //$process->setMode(Mage_Index_Model_Process::MODE_REAL_TIME)->save();
}