Gleb Paharenko wrote:
> 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.
