<< Looks like it's a query cache issue. In this case you get result from the cache.>>
That was it. THANKS!!!! ----- Original Message ----- From: "Victoria Reznichenko" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Monday, May 10, 2004 1:20 PM Subject: Re: Blocking Selects with LOCK TABLES > "Lou Olsten" <[EMAIL PROTECTED]> wrote: > > According to the docs (http://dev.mysql.com/doc/mysql/en/LOCK_TABLES.html) > > : > > If a thread obtains a READ lock on a table, that thread (and all other threads) can only > > read from the table. If a thread obtains a WRITE lock on a table, only the thread holding > > the lock can read from or write to the table. Other threads are blocked. > > > > So, I've got two threads going (T1, T2). > > > > T1 issues LOCK TABLES transtest WRITE; > > > > But when I go to T2, I can still issue: SELECT * FROM transtest; and retrieve all the > > data. I CANNOT update, so I know the command is at least partially working. As I > > understand it, I'm supposed to see a message from T2 that says something about "This > > table has been locked with the LOCK TABLES command." > > > > It is an InnoDB table, if that matters. > > Looks like it's a query cache issue. In this case you get result from the cache. > > > -- > For technical support contracts, goto https://order.mysql.com/?ref=ensita > This email is sponsored by Ensita.net http://www.ensita.net/ > __ ___ ___ ____ __ > / |/ /_ __/ __/ __ \/ / Victoria Reznichenko > / /|_/ / // /\ \/ /_/ / /__ [EMAIL PROTECTED] > /_/ /_/\_, /___/\___\_\___/ MySQL AB / Ensita.net > <___/ www.mysql.com > > > > > > -- > MySQL General Mailing List > For list archives: http://lists.mysql.com/mysql > To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED] > -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]
