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.
