At 04:22 AM 12/15/2003, you wrote:No no no!!! You've got it all wrong!!!!!
To elaborate on Dr Frank's thing if you're interested, here's a classic deadlock example:
1. Transaction A obtains an exclusive lock on a set of rows which we will call R1.
2. Transaction B obtains an exclusive lock on another set of rows which we will call R2.
3. Transaction A requests (but obviously doesn't acquire) an exclusive lock on R2.
4. Transaction B requests (but obviously doesn't acquire) an exclusive lock on R1.
5. Classic deadlock!
There are various ways of dealing with this (with timeouts and graph traversal seemingly popular). As you can see, neither transaction can go forward. Thus, the almighty InnoDB will think for a moment, decide which transaction it has something personal against, laugh at it and force it to ROLLBACK.
That transaction can then try again if it doesn't feel totally small and humiliated.
Hope this helps!
Regards,
Chris
Chris,
When my MySQL database gets into a deadlock situation like that, I just shutdown the server, power off the machine and go home. Works every time.<vbg>
Mike
(Sorry, it's been a late night)
You go and find the user who had the least involvement in causing the deadlock and scapegoat them!
Either that, or you use it as an excuse for doing one of the following things:
1. Getting the purchase of more hardware approved.
2. Getting the purchase of MySQL Pro and InnoDB Hot Backup approved
3. Getting a MySQL support contract purchase approved
4. Getting a raise for resolving the situation with poise, grace and subtlety (Eg: Shutting it down, blaming users, blaming SCO...)
Regards,
Chris
-- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]
