Hi all,

Apologies if this has been discussed before - a brief Google search did not
reveal anything of note, so I thought I'd go ahead and ask.

Just a few days before the go-live, and absolutely expectedly, I am getting
errors I have never seen before: Error Code 1213, Transaction Aborted due to
Deadlock. I have to use isolation level Serializable, and now my transactions
are immediately aborted if they would produce a deadlock. I should add our
transactions are very short (but critical).

I am somewhat surprised by this, in our concurrency tests we never encountered
anything the like before and I assumed the transaction manager could handle the
issue, delaying one transaction the tiniest moment until it could acquire a
lock. But well, go-live is nearing, and it's time for the freaky errors, I guess.

So my question: is this normal mySQL behaviour? Our DB admin assures me he
didn't change any timers or make any changes at all to the setup. The only
change that I made to my model before commencing the new test series was to
select two more cells than before, but I cannot believe this could be an issue.

As a workaround, I am catching the 1213 and wait a very short moment before
re-running the transaction. I still tend to think that the transaction manager
should be able to resolve such issues itself - does it?

Thanks for any answers,
Ralph