thanks,
Then I imagine, as a rule, I should be thinking about changing
that server variable to set selects to always have priority?
Without transactions, one should never have a situation
where any ill effects can result from delaying "users" that
issue live insert or update requests until the pending select
*queue* was empty.. after all, their requests are still done
in sequence, but they are delayed when doing updates until
the table handler has no current select work.
Typically, in a database backed website with a very high percentage
of selects to inserts, people do not "expect" update operations
(posts and so on) to complete very fast. But they do "expect"
page requests to be very fast.. the default behaviour does not
seem to meet this objective?
My only concern is that with a high frequency of ongoing selects,
perhaps in this mode an insert request will hang for far too long...
as there is "always something selecting" on a table.. anybody
with experience with a select-priority mysql server setup?
-Justin
On Fri, Mar 09, 2001 at 03:58:31PM +1300, Quentin Bennett wrote:
> Hi,
>
> Imagine the scenario of the following happening in quick succession:
>
> user1: select * from table --- ticks away, doing the select
> user2: select * from table --- also ticks away
> user3: insert into table ... --- locked!, waiting for selects
> to finish, so as not to disrupt them
> user4: select * from othertable --- ticks away, doing the select
> user4: select * from table --- locked!, has to wait for
> insert to finish, because result will depend on what the insert does
>
> This is why the later select (#13) is locked.
>
> Regards
>
> Quentin
>
> -----Original Message-----
> From: Justin [mailto:[EMAIL PROTECTED]]
> Sent: Friday, 9 March 2001 2:45 p.m.
> To: [EMAIL PROTECTED]
> Subject: locking oddity
>
>
> Hi,
> Can someone explain this?
>
> | 13 | XX | chrome | XX | Query | 1 | Locked | SELECT name FROM users WHERE
> uid=288950 |
> | 376 | XX | chrome | XX | Query | 1 | Sending data | SELECT uid FROM users
> WHERE name like '%Fuzzster' limit 1 |
> | 397 | XX | chrome | XX | Query | 1 | Locked | SELECT uid,flags,aseclev,
> ... etc
> | 479 | XX | blue-private | XX | Query | 0 | NULL | show processlist |
> | 542 | XX | chrome | XX | Query | 1 | Locked | update users set
> lllogin=llogin,visits=visits+1,llogin=NOW() where uid=333705 |
>
> I removed all the sleeping processes from the processlist
>
> * connection #397 is 'sending data' from a select. Fine.
>
> * connection #542 (an update) is "Locked" on that. Fine.
>
> * But ... why is connection #13 (another select) locked???
>
> And .. other examples show any other new selects also lock
> when there that or other pending locked updates are waiting...
> at least this is my interpretation..
>
> -Justin
>
> ---------------------------------------------------------------------
> Before posting, please check:
> http://www.mysql.com/manual.php (the manual)
> http://lists.mysql.com/ (the list archive)
>
> To request this thread, e-mail <[EMAIL PROTECTED]>
> To unsubscribe, e-mail
> <[EMAIL PROTECTED]>
> Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php
>
> The information contained in this email is privileged and confidential
> and intended for the addressee only. If you are not the intended
> recipient, you are asked to respect that confidentiality and not
> disclose, copy or make use of its contents. If received in error
> you are asked to destroy this email and contact the sender immediately.
> Your assistance is appreciated.
--
Justin Beech http://www.dslreports.com
Phone:212-269-7052 x252 FAX inbox: 212-937-3800
mailto:[EMAIL PROTECTED] --- http://dslreports.com/contacts
---------------------------------------------------------------------
Before posting, please check:
http://www.mysql.com/manual.php (the manual)
http://lists.mysql.com/ (the list archive)
To request this thread, e-mail <[EMAIL PROTECTED]>
To unsubscribe, e-mail <[EMAIL PROTECTED]>
Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php
