Re: Row Level Lock Contention - Daniel da Veiga - com.mysql.lists.win32

4 messages in com.mysql.lists.win32Re: Row Level Lock Contention

From	Sent On	Attachments
Melissa Dougherty	22 Nov 2004 09:55
Daniel da Veiga	22 Nov 2004 10:02
Melissa Dougherty	22 Nov 2004 10:19
Daniel da Veiga	22 Nov 2004 10:36

Subject:	Re: Row Level Lock Contention
From:	Daniel da Veiga (dani...@gmail.com)
Date:	11/22/2004 10:36:46 AM
List:	com.mysql.lists.win32

Hello again,

You can use the InnoDD monitors to see what locks are on, this is described at:

http://dev.mysql.com/doc/mysql/en/InnoDB_Monitor.html

I suppose that if you have the transaction index number you can kill it with no problems... But its always best to tune your software to avoid deadlocks, there are some tips at:

http://dev.mysql.com/doc/mysql/en/Innodb_deadlocks.html

In section "How to cope with deadlocks".

Hope that helps,

On Mon, 22 Nov 2004 13:19:30 -0500, Melissa Dougherty

<meli...@cse-corp.com> wrote:

Yes.... you are right. This is the way it behaves.

The problem is the first query that caused the initial lock. If that user disconnect incorrectly, the record does not free. How do you see these locks/free them?

Hello Melissa,

There's a startup variable for the MySQL Server called innodb_lock_wait_timeout that is the time in seconds to wait before roll back the transaction and release the lock at the lock table. Innodb is very smart and can notice deadlocks, but if you have this problem, it may be an exception and you should set this variable.

Best regards,

On Mon, 22 Nov 2004 12:55:30 -0500, Melissa Dougherty <meli...@cse-corp.com> wrote:

I have an InnoDB MySQL database setup with an application that uses statements like... "SELECT COL1 FROM TABLE WHERE COL1='X' FOR UPDATE" causing a row lock for that record. If the user does not commit or cancel the transaction correctly, the row lock does not get cleaned up.

How can I see that lock and cleanup that lock after a user exits the application incorrectly?

Thanks,

Melissa