does the "lock table" on MySQL (I'm using 5.0.22 or 5.0.45) works
even for a cached result?

this is my scenario, (I'm using MyIsam tables)

thread 1:
LOCK TABLE foo WRITE;

thread 2:
SELECT * FROM foo ;
(locked)

thread 1:
UNLOCK TABLES;

thread 2:
result of SELECT * ..

and that's is, IMHO, correct; btw, if the result of the select is in
the cache, it seems that I'm unable to 'lock' again the table:

thread 1:
LOCK TABLE foo WRITE;

thread 2:
SELECT * FROM foo ;
I have the result of the select; that was not 'locked'

the only way I found to avoid that is use the SQL_NO_CACHE (then
SELECT SQL_NO_CACHE FROM foo)

is that correct?! there is a way to avoid to specify "SQL_NO_CACHE" ?
or there is something wrong ?!
thank you in avance.
bye bye
marco

On Wed, Mar 12, 2008 at 3:15 PM, MAS! <urkapd@libero.it> wrote:
> does the "lock table" on MySQL (I'm using 5.0.22 or 5.0.45) works
> even for a cached result?

Hold your horses, dude. That's the third time you sent that
email. Someone will give you an answer if you're patient.

If you can't wait (or don't feel like it), check out the forum at
http://www.mysqlfreaks.com/.

Best of luck, Marco!

--
</Dan>

Daniel P. Brown
Senior Unix Geek
<? while(1) { $me = $mind--; sleep(86400); } ?>

On Wed, Mar 12, 2008 at 3:22 PM, Daniel Brown <parasane@gmail.com> wrote:
> On Wed, Mar 12, 2008 at 3:15 PM, MAS! <urkapd@libero.it> wrote:
> > does the "lock table" on MySQL (I'm using 5.0.22 or 5.0.45) works
> > even for a cached result?
>
> Hold your horses, dude. That's the third time you sent that
> email. Someone will give you an answer if you're patient.

I agree. Don't duplicate posts or post to multiple lists. Jump on
the IRC channel if you need right away :-)

The query_cache_wlock_invalidate server variable controls the behavior
you are seeing. You can configure it as desired.

Baron

MAS! wrote:
> does the "lock table" on MySQL (I'm using 5.0.22 or 5.0.45) works even
> for a cached result?
>
> this is my scenario, (I'm using MyIsam tables)
>
> thread 1:
> LOCK TABLE foo WRITE;
>
> thread 2:
> SELECT * FROM foo ;
> (locked)
>
> thread 1:
> UNLOCK TABLES;
>
> thread 2:
> result of SELECT * ..
>
> and that's is, IMHO, correct; btw, if the result of the select is in the
> cache, it seems that I'm unable to 'lock' again the table:
>
> thread 1:
> LOCK TABLE foo WRITE;
>
> thread 2:
> SELECT * FROM foo ;
> I have the result of the select; that was not 'locked'
>
> the only way I found to avoid that is use the SQL_NO_CACHE (then SELECT
> SQL_NO_CACHE FROM foo)
>
> is that correct?! there is a way to avoid to specify "SQL_NO_CACHE" ?
> or there is something wrong ?!

Try setting query_cache_wlock_invalidate to ON.

Werner

> I agree. Don't duplicate posts or post to multiple lists. Jump on
> the IRC channel if you need right away :-)

sorry again, I was not in hurry, but I had a fault on my mailer,
since I was trying to send the post from office and from the wrong
account..

> The query_cache_wlock_invalidate server variable controls the behavior
> you are seeing. You can configure it as desired.

thank you so much to all..

by
MAS!