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:
And also in the documentation:
Also, you might want to look at InnoDB's store_lock.