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
[EMAIL PROTECTED]
On Mon, 18 Oct 2004 16:58:04 -0700, Aaron <[EMAIL PROTECTED]> 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
>
>
--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]
