Its ok @
Mike helped me and got it resolved.
Thanks to everyone that tried to help.
What did he do ... so others in the future can be helped ?
I read this on stackoverflow ... it's how to avoid deadlocks from a programming perspective ... so I guess it won't help.
If you are using InnoDB or any row-level transactional RDBMS, then it is possible that any write transaction can cause a deadlock, even in perfectly normal situations. Larger tables, larger writes, and long transaction blocks will often increase the likelihood of deadlocks occurring. In your situation, it's probably a combination of these.
The only way to truly handle deadlocks is to write your code to expect them. This generally isn't very difficult if your database code is well written. Often you can just put a try/catch around the query execution logic and look for a deadlock when errors occur. If you catch one, the normal thing to do is just attempt to execute the failed query again.
I highly recommend you read
this page in the MySQL manual. It has a list of things to do to help cope with deadlocks and reduce their frequency.
this page is ..
http://dev.mysql.com/doc/refman/5.0/en/innodb-deadlocks.html
Deadlocks are a classic problem in transactional databases, but they are not dangerous unless they are so frequent that you cannot run certain transactions at all. Normally, you must write your applications so that they are always prepared to
re-issue a transaction if it gets rolled back because of a deadlock.
InnoDB uses automatic row-level locking. You can get deadlocks even in the case of transactions that just insert or delete a single row. That is because these operations are not really “atomic”; they automatically set locks on the (possibly several) index records of the row inserted or deleted.
Sounds like these deadlocks are inevitable.
