> It only uses table based locking and it treats updates with a higher
> priority than reads. That means that if you start a read query that takes
> 60 seconds to execute, you can continue other reads just fine during that
> period, _until_ you queue an update request on that table. Once you do
> that, then nothing else (read or write) can access the table until the 60
> second read finishes, then the update finishes.
>
> So even though you are not executing any update that will lock the table
> and take a long time to do the query, it can still be locked for a long
> time.
>
> It can have quite a significant impact on high traffic websites doing a
> high number of normally cheap queries, since it backs up the webserver and
> jserv quite horribly; you have to ensure that your code can gracefully
> deal with such failures without choking everything up. Otherwise, you can
> end up in errors being spit back from jserv that look something horrible.
> This also presents difficulties in running a 24x7 site if you need to do
> batch updates to info in the database, since you essentially have to take
> the site offline to do that with mysql.
>
> But this is getting off topic...
so to get even further off topic, you can use the DELAYED or
LOW_PRIORITY inserts and updates features of Mysql to get around these
table locking issues (LOW_PRIORITY insert or update waits until no other
clients are reading from the table before running; DELAYED inserts allow
the client to return immediately while Mysql queues up the inserts for
later insertion -- see Mysql reference manual for further details) -- so
in most cases (especially where we don't care about the order in which
queries get executed) we can have long running queries concurrent with
quick selects & updates/inserts.
----------------------------------------------------------------------
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
