I have an a problem and I cannot resolve.

I don’t know how I can resolve this:

Transaction 1

START TRANSACTION;

UPDATE `sginfra_actas` SET `act_estado_id` = ‘9′ WHERE `act_id` = ‘3713′
(Affected Row = 1)

Other statments….

UPDATE `sginfra_actas` SET `act_estado_id` = ‘9′ WHERE `act_id` = ‘3713′
(Affected Row = 0)

I’m in the same transactions.
Why there is a lock?

Thansk

Gaditano

The correct way to use LOCK TABLES and UNLOCK TABLES with transactional tables, such as InnoDB tables, is to begin a transaction with SET AUTOCOMMIT = 0 (not START TRANSACTION) followed by LOCK TABLES, and to not call UNLOCK TABLES until you commit the transaction explicitly. When you call LOCK TABLES, InnoDB internally takes its own table lock, and MySQL takes its own table lock. InnoDB releases its internal table lock at the next commit, but for MySQL to release its table lock, you have to call UNLOCK TABLES. You should not have AUTOCOMMIT = 1, because then InnoDB releases its internal table lock immediately after the call of LOCK TABLES, and deadlocks can very easily happen. InnoDB does not acquire the internal table lock at all if AUTOCOMMIT=1, to help old applications avoid unnecessary deadlocks.

A deadlock is like Peter explains, but basically you are saying the same.
So to combine both explanations just consider two transactions A en B and
one table with rows r1 and r2 in it. Transactions A locks r1, and
transaction B locks r2, then transaction A wants to lock r2 but has to
wait to get it, and finally transaction B wants to lock r1 but also has
to wait. In this scenario transaction A and B are waiting for eachother
and neither one can ever proceed which is called a deadlock.

As to why table locks are more efficient is because of this:
When a transaction wants to access a table it first checks if there is
a table lock sitting on it. Only after doing this check, row locks come
into play. So there are actually two levels of locking, first the table
lock, only then the row locks. Checking only a single table lock is
less overhead then having to check multiple row locks.

If one thread just tries to lock the resouce which is already locked lock wait happens. If however the locking thread holds resources other threads is waiting for (most simple case) wait would happen forever and it is called deadlock.

Why Innodb locks row level locks always is because it is designed this way

Also, when you say: “Lock table Innodb can lock tables but it will still need to set row level locks which is memory and CPU overhead. For some bulk operations it would be more efficient to use table locks.”, I am curious as to why, if the whole table is locked, row level locks are still needed.

I would suggest to try it with recent MySQL 5.0 version and if it still happens report it at bugs.mysql.com

I don’t know about GET_LOCK/RELEASE_LOCK.

p.s: did you know that a
‘SELECT id into tmp from mf_banners where id=192 LOCK IN SHARE MODE’
together with ‘REPEATABLE_READ’ suffices to get serializability?