Bug #36634 LOCK TABLE: cannot acquire transactional lock
Submitted: 9 May 2008 18:35 Modified: 2 Apr 2009 8:57
Reporter: Paul DuBois Email Updates:
Status: Can't repeat Impact on me:
None 
Category:MySQL Server: InnoDB storage engine Severity:S3 (Non-critical)
Version:6.0.6 OS:Any
Assigned to: Anurag Shekhar CPU Architecture:Any
Tags: v6

[9 May 2008 18:35] Paul DuBois
Description:
The following script acquires a transactional lock after beginning transaction two different ways:

- Using an explicit BEGIN
- Using SET to disable autocommit

drop table if exists t;
create table t (i int) engine innodb;
show create table t\G

begin;
lock table t in share mode;
show warnings;
commit;
set autocommit=0;
lock table t in share mode;
show warnings;

The script works in 6.0.5, and until recently worked in 6.0.6 (current BK tree). But now it malfunctions in 6.0.6. The type of malfunction is different for the two attempts to acquire the lock, but on both cases it appears that the server is wrongly attempting to convert the lock request to a request for a non-transactional lock.

How to repeat:
Script output when it works (6.0.5):

mysql> drop table if exists t;
Query OK, 0 rows affected (0.08 sec)

mysql> create table t (i int) engine innodb;
Query OK, 0 rows affected (0.08 sec)

mysql> show create table t\G
*************************** 1. row ***************************
       Table: t
Create Table: CREATE TABLE `t` (
  `i` int(11) DEFAULT NULL
) ENGINE=InnoDB DEFAULT CHARSET=latin1
1 row in set (0.01 sec)

mysql> 
mysql> begin;
Query OK, 0 rows affected (0.00 sec)

mysql> lock table t in share mode;
Query OK, 0 rows affected (0.00 sec)

mysql> show warnings;
Empty set (0.00 sec)

mysql> commit;
Query OK, 0 rows affected (0.00 sec)

mysql> set autocommit=0;
Query OK, 0 rows affected (0.00 sec)

mysql> lock table t in share mode;
Query OK, 0 rows affected (0.00 sec)

mysql> show warnings;
Empty set (0.00 sec)

Script output when it malfunctions (current BK sources):

mysql> drop table if exists t;
Query OK, 0 rows affected (0.01 sec)

mysql> create table t (i int) engine innodb;
Query OK, 0 rows affected (0.22 sec)

mysql> show create table t\G
*************************** 1. row ***************************
       Table: t
Create Table: CREATE TABLE `t` (
  `i` int(11) DEFAULT NULL
) ENGINE=InnoDB DEFAULT CHARSET=latin1
1 row in set (0.01 sec)

mysql> 
mysql> begin;
Query OK, 0 rows affected (0.00 sec)

mysql> lock table t in share mode;
ERROR 1615 (HY000): Cannot convert to non-transactional lock in an active transaction on 't'
mysql> show warnings;
+-------+------+--------------------------------------------------------------------------+
| Level | Code | Message                                                                  |
+-------+------+--------------------------------------------------------------------------+
| Error | 1615 | Cannot convert to non-transactional lock in an active transaction on 't' | 
+-------+------+--------------------------------------------------------------------------+
1 row in set (0.00 sec)

mysql> commit;
Query OK, 0 rows affected (0.00 sec)

mysql> set autocommit=0;
Query OK, 0 rows affected (0.00 sec)

mysql> lock table t in share mode;
Query OK, 0 rows affected, 1 warning (0.00 sec)

mysql> show warnings;
+---------+------+--------------------------------------------+
| Level   | Code | Message                                    |
+---------+------+--------------------------------------------+
| Warning | 1613 | Converted to non-transactional lock on 't' | 
+---------+------+--------------------------------------------+
1 row in set (0.00 sec)
[11 May 2008 5:59] Sveta Smirnova
Thank you for the report.

Verified as described.
[30 Sep 2008 14:05] Kevin Lewis
Falcon does not implement any file locks.  This is done in the server.  The error mentioned originates from \sql\lock.cc, line 1528.  Since a previous comment says that transactional locks were first put into 6.0.3, I think the server team should investigate and determine what is going wrong, or what changed in 6.0.6.
[2 Apr 2009 8:54] Sveta Smirnova
I can not repeat this anymore.
[2 Apr 2009 8:57] Anurag Shekhar
Its not reproducible in latest code base. Probably got fixed as side effect of some code change.