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]
