Every new connection is considered a client. It's a bad idea to try to
do your own scheduling client side to try to defeat table locks
because MySQL can proceed with other clients as soon as the locks are
freed vs your application waiting for a complete result set to return
before proceeding with another query from a different client. Not to
mention the over head of scheduling on the client side. If you have
enough lock contention for table locks to be a problem you should
switch to the InnoDB storage engine.
On Mon, 18 Oct 2004 16:58:04 -0700, Aaron <wigsy@stripped> wrote:
> Hi all ,
> I have a quick question regarding table locking.
> This is a snippet referring to when table locking is disadvantageous:
> "Another client issues another SELECT statement on the same table. Because UPDATE has
> higher priority than SELECT, this SELECT will wait for the UPDATE to finish. It will also
> wait for the first SELECT to finish!"
> So what constitutes a new client exactly? We use Perl and DBI to connect to MySQL.
> Does this mean that everytime we connect to the DBase it is considered a new client? If so
> , would some form of connection pooling/caching help reduce the lock delays on a slow
> SELECT statement?
> Thanks !