Saya mengalami masalah di mana saya percaya proses pengindeksan ulang Harga Produk menyebabkan pengecualian kebuntuan dalam proses checkout.
Saya menangkap pengecualian ini dalam proses checkout:
Pengecualian konversi pesanan: SQLSTATE [40001]: Kegagalan serialisasi: 1213 Deadlock ditemukan saat mencoba mendapatkan kunci; coba mulai kembali transaksi
Sayangnya saya tidak memiliki jejak tumpukan penuh karena di mana pengecualian ditangkap, tetapi memeriksa status INNODB saya dapat melacak kebuntuan:
SELECT `si`.*, `p`.`type_id` FROM `cataloginventory_stock_item` AS `si`
INNER JOIN `catalog_product_entity` AS `p` ON p.entity_id=si.product_id
WHERE (stock_id=1)
AND (product_id IN(47447, 56678)) FOR UPDATE
*** (1) WAITING FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 0 page no 329624 n bits 352 index
`PRIMARY` of table `xxxx`.`catalog_product_entity`
Kunci tabel permintaan SQL pada akhirnya dihasilkan dari Mage_CatalogInventory_Model_Stock::registerProductsSale()
ketika mencoba untuk mendapatkan jumlah persediaan saat ini untuk menurunkannya.
Pada saat kebuntuan terjadi, proses indeks ulang Harga Produk sedang berjalan dan saya berasumsi itu memiliki kunci baca catalog_product_entity table
yang menyebabkan kebuntuan. Jika saya memahami kebuntuan dengan benar setiap kunci baca akan menyebabkan kebuntuan, tetapi indeks harga produk menahan kunci untuk waktu yang adil karena situs memiliki ~ 50.000 produk.
Sayangnya, pada titik ini dalam alur kode checkout, kartu kredit pelanggan telah ditagih (melalui modul pembayaran khusus), dan pembuatan objek pesanan yang sesuai gagal.
Pertanyaan saya adalah:
- Apakah logika modul pembayaran khusus salah? yaitu apakah ada aliran yang diterima untuk memastikan bahwa Magento dapat mengubah penawaran menjadi pengecualian pesanan gratis sebelum melakukan tagihan ke metode pembayaran (kartu kredit)?
Sunting: Tampaknya logika modul pembayaran memang salah karena panggilan ke $ paymentmethod-> otorize () harus terjadi setelah tempat kebuntuan ini terjadi, bukan sebelumnya (sesuai jawaban Ivan di bawah). Namun, transaksi masih akan diblokir oleh jalan buntu (meskipun tanpa biaya sesat ke kartu kredit).
Ini panggilan fungsi
$stockInfo = $this->_getResource()->getProductsStock($this, array_keys($qtys), true);
dalamMage_CatalogInventory_Model_Stock::registerProductsSale()
merek itu penguncian membaca, betapa berbahayanya itu akan membuatnya non-penguncian membaca?Dalam mencari jawaban di web, beberapa tempat menyarankan tidak menjalankan pengindeksan ulang penuh saat situs sedang panas; sepertinya bukan solusi yang bagus; Apakah masalah pengindeksan menyebabkan kebuntuan tabel dan pertikaian kunci masalah yang dikenal di Magento, apakah ada solusi?
Sunting: Tampaknya pertanyaan yang tersisa di sini adalah pertanyaan dari pertanyaan ketiga; pengindeksan ulang menyebabkan kebuntuan tabel. Mencari solusi untuk ini.
Sunting: Konsep bahwa kebuntuan tidak ada dalam dan tentang masalah mereka sendiri, melainkan tanggapan terhadap mereka harus menjadi fokus, masuk akal. Investigasi lebih lanjut untuk menemukan titik dalam kode untuk menangkap pengecualian kebuntuan dan menerbitkan kembali permintaan. Melakukan hal ini pada tingkat adaptor DB Zend Framework adalah satu pendekatan, tetapi saya juga mencari cara untuk melakukan ini dalam kode Magento untuk memudahkan pemeliharaan.
Ada tambalan yang menarik di utas ini: http://www.magentocommerce.com/boards/viewthread/31666/P0/ yang tampaknya mengatasi kondisi kebuntuan terkait (tapi bukan yang ini secara khusus).
Sunting: Rupanya kebuntuan telah diatasi pada gelar di CE 1.8 Alpha. Masih mencari solusi hingga versi ini keluar dari Alpha