Geoff hendrey <[EMAIL PROTECTED]> writes: > Hi Knut, > > Thanks. That's what it looked like to me too. If the two transactions were > both trying drop the same column, just curious why they would obtain locks on > table XXX and the SYSCONGLOMERATES table in opposite orders, which seems like > a recipe for deadlock.
Normally, they should take the locks in the same order. According to the stacktrace, the deadlock happens while executing a batch of statements. Perhaps the transactions have performed other operations before they try to alter the table, and therefore are holding some extra locks? > Also, would it make sense to use isolation level TRANSACTION_SERIALIZABLE for > performing any modifications to the structure of a table? Would that prevent > the deadlock? Not necessarily. It may work both ways, depending on the combination of operations leading up to the deadlock. -- Knut Anders
