Bug #12081 Cluster: BEGIN after lock-wait timeout results in error 1296

• Submitted: 21 Jul 2005 13:17
• Modified: 27 Sep 2005 9:21
• Reporter: Jan Kneschke
• Status: Can't repeat
• Category: MySQL Cluster: Cluster (NDB) storage engine
• Severity: S3 (Non-critical)
• Version: 4.1.12
• OS: Linux (Linux/x86)
• Assigned to: Martin Skold
• CPU Architecture: Any

[21 Jul 2005 13:17] Jan Kneschke

Description:
BEGIN after transaction abort results in error 1296

The reported lockwait appears immediatly and doesn't look like a timeout at all.

How to repeat:
open 2 transactions: 
- trans1
- trans2

SELECT id FROM tbl;
1
2
3
4

trans1:
BEGIN;
UPDATE tbl SET id = 15 WHERE id = 1;
Query OK, 1 row affected

trans2:
BEGIN;
UPDATE tbl SET id = 16 WHERE id = 2;
Query OK, 1 row affected

trans1:
UPDATE tbl SET id = 17 WHERE id = 2;
ERROR 1205 (HY000): Lock wait timeout exceed; try restarting transaction

BEGIN;
ERROR 1296 (HY000): Get error 4350 'Transaction already aborted' from ndbcluster;

BEGIN;
Query OK, 0 rows affected

Suggested fix:
If deadlock occurs wait the full TransactionDeadlockDetectionTimeout before detecting the deadlock and don't report the ERROR 1296.

[21 Jul 2005 18:12] Jorge del Conde

Hi!

I was able to reproduce this bug w/4.1.12.

[16 Sep 2005 5:08] Tomas Ulin

what had you set the timeout to?

The default is quite small... 1.2 secs,  that can be interpreted as "immediate"

Just yesterday I had it set larger in a similar case and it seems to work ok.

[27 Sep 2005 9:21] Martin Skold

Increased TransactionDeadlockDetectionTimeout= 10000
and it seems to wait as it should (in 4.1.15).