Mysql InnoDB table locked but I can "select" from another session. What gives?

During my development of some code, I needed to 'write l开发者_StackOverflowock' an InnoDB table in order to avoid race conditions concurrency problems. 'read lock' is not good enough as some parallel session that will 'read' a locked table (locked by other session) will get false data as what it reads might evaporate (deleted) once the locking session finishes its job.

Thus far as to why I need 'write lock'. Comments are welcome on this but it will simply take long to explain why (to my humble mind) I cannot see any way other than complete terminal lock of the table.

Now, for my tests, I have opened two mysql command line sessions, both with regular user (no root or similar). In one session I did: lock tables mytable write; which resulted ok (uery OK, 0 rows affected...) On the second command line session I connected to same DB and run a simple select * on the same table. To my surprise I got a full response. In more tests from the actual web application I did notice that on some use cases that involve the web app (PHP + PDO with persistent connections attribute on) a command line or web mysql connectivity did block until the lock was released but I did not identified what exactly caused this (desired) effect, and it involves also different environment (PHP + PDO as detailed and command line vs. 2 command line sessions).

My question is: why? why wouldn't the second command line session, running a simple 'select' on the write-locked table blocked?

Does this has to do with the nature of InnoDB locks which is row-based? If so, how exactly does this relate? How do I get such a simple lock implemented on an InnoDB table. I know I can create a 'semaphore' MyIsam table with no purpose other than act as a 'traffic light' but that will lose the effect of DB level protection and will move all the protection to be done (or wrongly done) in the app level.

TIA!

MySQL version is 5.1.54 (Ubuntu 11.04).

While InnoDB has row level locking, it also has multi-version concurrency control http://en.wikipedia.org/wiki/Multiversion_concurrency_control, so this means that readers don't need to be blocked by writers. They can just see the current version of the record. (Technical implementation, on update the row is modified in place and the previous edition will be written to undo space for older transactions.)

If you want to make the write lock block readers, you need to change the SELECT to be FOR UPDATE (i.e. SELECT * FROM my_table WHERE cola = n FOR UPDATE).