6 messages in com.mysql.lists.mysqlRe: Understanding Table Locking
FromSent OnAttachments
Jay Miller18 May 1999 07:01 
Christian Mack18 May 1999 09:06 
unkn...@riverstyx.net18 May 1999 12:52 
Erik E Rantapaa18 May 1999 17:19 
Paul DuBois18 May 1999 17:32 
Michael Widenius23 May 1999 16:53 
Subject:Re: Understanding Table Locking
From:Christian Mack (Ma@compal.de)
Date:05/18/1999 09:06:37 AM
List:com.mysql.lists.mysql

Jay Miller wrote:

I have read that --skip-locking is enabled by default on Linux systems because of a bug in the Linux file locking mechanism. This leads me to wonder about when locking is important with MySQL.

I have one MySQL daemon running on Slackware Linux 2.2.5. There are several tables and many client machines, but there are two clients that both INSERT into the same large (+3 million records) table multiple times per second. This table becomes corrupt somewhat regularly. Is there potentially a problem with more than one MySQL thread updating the table at the same time? Or does MySQL handle preventing this sort of problem?

Thanks,

Jay Miller

Hi Jay

The --skip-locking has nothing to do with multiple client access. Mysql provides a locking mechanism for this in itself.

This flag only prevents locking of the data files on the filesystem level. This filesystem locking only is useful, if two mysqld servers are using the same
data files. With two servers running there is a chance, that both servers try to UPDATE,
INSERT or DELETE the same table file. This only can be syncronized on filesystem level, because the two mysql servers
don't know each other. If you don't run two mysql servers (or one mysql server and an isamchk) on the
same data files, you never need this filesystem locking mechanism.

Tschau Christian