List:General Discussion« Previous MessageNext Message »
From:Eric Bergen Date:October 19 2004 3:14am
Subject:Re: Table Lock Delays and Connection Pooling
View as plain text  
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.

Eric Bergen

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 !
> Aaron
Table Lock Delays and Connection PoolingAaron19 Oct
  • Re: Table Lock Delays and Connection PoolingEric Bergen19 Oct