Hello.
Among other things check that you correctly process lock timeouts.
I've check this, but it seems fine.
I'm testing it this way with 3 applications on the same computer (2 processors) :
- 2 clients applications with an open connection to the DB (which is remote with single processor) are waiting for a event to be trigger by the network. When the event comes they fire the query (BEGIN; SELECT ... FOR UPDATE; do stuff; COMMIT/ROLLBACK ).
- 1 supervisor application that send those events to the clients applications (in order to reproduce production conditions). If I send the two event without delay ( send client1; send client2 ) the SELECT .. FOR UPDATE goes through for the _two_ clients at the same time and then cause InnoDB to complain about a deadlock.
If i introduce a delay of 20 ms (send client1; sleep(20 ms); send client 2); only one SELECT .. FOR UPDATE goes through, the other one does wait until it's commited/rollback as expected (and so reproduce what I can observe if I do it by hand).
The problem is just that if the two SELECT ... FOR UPDATE does arrive at the same time, it throws a deadlock. Well, if that's the expected behaviour, it's fine with me, but I still don't undestand why it does happen.
Thanks for your help,
Well, I'm sure it's a bug hidden somewhere in my apps, i've check with another connexion and it worked ;)
-- Philippe Poelvoorde COS Trading Ltd.
-- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]
