From: Date: July 2 2009 10:54pm
Subject: Re: store_lock (turning off all locks)
List-Archive: http://lists.mysql.com/internals/37072
Message-Id: <4A4D1E6F.4060305@Sun.COM>
MIME-Version: 1.0
Content-Type: text/plain; CHARSET=US-ASCII; format=flowed
Content-Transfer-Encoding: 7BIT

On 7/2/09 5:38 PM, Slava Akhmechet wrote:
> On Thu, Jul 2, 2009 at 12:46 PM, Konstantin Osipov<kostja@stripped>  wrote:
>> Can your engine process DROP TABLE concurrently with SELECT?
> Actually, at least on Linux this isn't very difficult since the kernel
> reference counts the inodes. If one thread unlinks the files while the
> other is reading them, that's no problem.
>
>> Do you really want MySQL statements LOCK TABLE<table>  WRITE and
>> FLUSH TABLE have no effect on your engine, i.e. allow them to
>> proceed concurrently with all statements and each other?
> May be. If full isolation is implemented efficiently, it might be
> reasonable to implement LOCK TABLE as a noop. Anyway, I am concerned
> with understanding how store_lock (and MySQL locking) works, and I'm
> doing some trial and error for the learning process. This part of the
> trial is downgrading all locks to no locking and seeing what happens
> :) Could someone clear up how to do that?

There are a handful of resources around this in the forge:

http://forge.mysql.com/w/index.php?title=MySQL_Internals_Custom_Engine&printable=yes#Implementing_the_store_lock.28.29_Method

http://forge.mysql.com/w/index.php?title=MySQL_Internals_Custom_Engine&printable=yes#14.17.25.store_lock

http://forge.mysql.com/wiki/MySQL_Internals_Locking_Overview

And also in the documentation:

http://dev.mysql.com/doc/refman/5.1/en/locking-issues.html
http://dev.mysql.com/doc/refman/5.1/en/sql-syntax-transactions.html

Also, you might want to look at InnoDB's store_lock.