On Wed, Nov 2, 2011 at 11:33 AM, Tom Evans <tevans...@googlemail.com> wrote: >> other connections in other transactions are locked too? > > Yes. The exact wording from the C API: > > """ > On the other hand, you shouldn't use mysql_use_result() if you are > doing a lot of processing for each row on the client side, or if the > output is sent to a screen on which the user may type a ^S (stop > scroll). This ties up the server and prevent other threads from > updating any tables from which the data is being fetched. > """
this seems to be the case with MyISAM tables; on the InnoDB engine docs, it says that SELECT statements don't set any lock, since it reads from a snapshot of the table. on MyISAM, there are (clumsy) workarounds by forcing the use of scratch tables, explicitly copying to temporary tables, or buffering the output. """ SELECT ... FROM is a consistent read, reading a snapshot of the database and setting no locks unless the transaction isolation level is set to SERIALIZABLE. For SERIALIZABLE level, the search sets shared next-key locks on the index records it encounters. """ (http://dev.mysql.com/doc/refman/5.0/en/innodb-locks-set.html) -- Javier -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
