![]() ![]() #8 /home/catering/public_html/shop/app/code/core/Mage/Log/Model/Visitor.php(167): Mage_Core_Model_Abstract->save() #7 /home/catering/public_html/shop/app/code/core/Mage/Core/Model/Abstract.php(318): Mage_Core_Model_Resource_Db_Abstract->save(Object(Mage_Log_Model_Visitor)) #6 /home/catering/public_html/shop/app/code/core/Mage/Core/Model/Resource/Db/Abstract.php(453): Zend_Db_Adapter_Abstract->insert('shop_log_visito.', Array) ![]() #5 /home/catering/public_html/shop/lib/Zend/Db/Adapter/Abstract.php(574): Varien_Db_Adapter_Pdo_Mysql->query('INSERT INTO `sh.', Array) #4 /home/catering/public_html/shop/lib/Varien/Db/Adapter/Pdo/Mysql.php(419): Zend_Db_Adapter_Pdo_Abstract->query('INSERT INTO `sh.', Array) #3 /home/catering/public_html/shop/lib/Zend/Db/Adapter/Pdo/Abstract.php(238): Zend_Db_Adapter_Abstract->query('INSERT INTO `sh.', Array) #2 /home/catering/public_html/shop/lib/Zend/Db/Adapter/Abstract.php(479): Zend_Db_Statement->execute(Array) #1 /home/catering/public_html/shop/lib/Zend/Db/Statement.php(300): Varien_Db_Statement_Pdo_Mysql->_execute(Array) Trace: #0 /home/catering/public_html/shop/lib/Varien/Db/Statement/Pdo/Mysql.php(110): Zend_Db_Statement_Pdo->_execute(Array) The most efficient way to do it is to have all involved methods to enter an explicit transaction: SET autocommit = 0 Otherwise, you can resort to explicit transactions plus table level locking with LOCK TABLE form_responses WRITE. ![]() ![]() the WHERE needs to lock 7262 rows (!), which from the application logic's point of view is completely nonsensical (see also this for an explanation of "gapping"). This is a very strong hint: 2616 lock struct(s), heap size 244152, 7262 row lock(s) Notice that here the logical error is in transaction TWO's query. Record lock, heap no 5 PHYSICAL RECORD: n_fields 18 compact format info bits 0 RECORD LOCKS space id 866959 page no 68831 n bits 72 index `PRIMARY` of table `schema`.`table` trx id 22B8A76B4 lock_mode X locks rec but not gap waiting *** (2) WAITING FOR THIS LOCK TO BE GRANTED: Record lock, heap no 1 PHYSICAL RECORD: n_fields 1 compact format info bits 0Ġ: len 7072656d756d asc supremum RECORD LOCKS space id 866959 page no 46 n bits 1616 index `NewIndex2` of table `schema`.`table` trx id 22B8A76B4 lock_mode X MySQL thread id 11161676, OS thread handle 0x7fd06ca97700, query id. TRANSACTION 22B8A76B4, ACTIVE 0 sec fetching rowsĢ616 lock struct(s), heap size 244152, 7262 row lock(s) MySQL thread id 11161737, OS thread handle 0x7fd06d708700, query id. LOCK WAIT 4 lock struct(s), heap size 1248, 4 row lock(s) TRANSACTION 22B8A76B9, ACTIVE 0 sec starting index read For instance you'll find: LATEST DETECTED DEADLOCK Note that it is not at all a given that your deadlock is in that table you should run SHOW ENGINE INNODB STATUS to see what the last detected deadlock was. The easiest - not, I hasten to say, the most efficient! - way to overcome this problem is probably to resort to advisory locking if you find out that the updates all happen in the same small set of methods. Problem is, the application or the ORM are using it the wrong way, not giving MySQL sufficient information on what is to be done, resulting in a deadlock. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |