Re: my confusion, I guess your view code could be relying on MySQL to block any reads from the table while any thread held the write lock, so that is why you say the view code did nothing with locks? In which case you are right, I don't understand how that thread would get an OperationalError related to locks. I just tried what I think you are trying to do with my own setup and it worked as expected -- code that read from a table blocked while the write lock was held by a python shell thread, and then proceeded normally once I released the lock in the shell.
Another thing to watch out for is that you must obtain the locks using any alias that is going to be used in queries. I'm not sure if/when Django code aliases table names in queries....but I think I have seen it. So this table locking approach may require a tighter coupling to exactly how Django constructs queries than you might desire. Karen On 10/30/07, Karen Tracey <[EMAIL PROTECTED]> wrote: > > On 10/30/07, Peter <[EMAIL PROTECTED]> wrote: > > > > This worked in the trivial case of one user in the django python > > shell. > > > > However, when I tried to load a page that tried to read the table - > > while it was still write locked - the page was not returning (as I > > would expect), so I unlocked the tables from within the python shell > > and then I received an OperationalError suggesting that the browser > > view had screwed up locks (even though there was nothing in the view > > code that called the locking methods - maybe this was middleware?) -- > > "Table '<table_name>' was not locked with LOCK TABLES" > > > I find this paragraph very confusing -- surely the view code did call the > locking method, else why would you have expected the browser view to block > until you released the locks in the shell? Anyway, my guess is you are > running afoul of this, from the MySQL docs ( > http://dev.mysql.com/doc/refman/5.0/en/lock-tables.html): > > When you use LOCK TABLES, you must lock all tables that you are going to > use in your statements. While the locks obtained with a LOCK TABLESstatement > are in effect, you cannot access any tables that were not locked > by the statement. > > If you try to access a table you have not locked, you will get an > OperationalError naming the table you have tried to access and stating that > it was not locked with LOCK TABLES. Perhaps select_related() or something > is pulling in a join on a table you weren't expecting? > > Karen > > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~----------~----~----~----~------~----~------~--~---
