Tag Info

New answers tagged

0

Assuming you're working with read committed isolation level (=the default), then the deadlock will happen when a reads the row, then b reads the row, then a tries to update it and then b tries to update it. In addition to deadlocks you might have another problem if you're dealing with the same rows and the process isn't that fast, since the second process ...


4

Order of table scan is never guaranteed. Order in which rows are locked is not guaranteed either. In addition, SQL Server has lock escalation, so you can't really say what the engine decides to lock, row, page, or table itself. Thus, deadlock may happen even if values of @id are different in concurrent sessions, but rows of interest happened to reside on ...


0

I failed to understand the extent of the transactions. Before I do the INSERT, I do a write-locking select on the external index value in both transactions. I would have expected T2 to block T1 at that point, but that is not the case, both transactions successfully acquire a lock on the gap. Neither transaction can promote its lock to insert intention; T1 ...


0

Please look carefully at the query and their locks Both INSERT queries are trying to INSERT a new row at space id 18 page no 1103450 n bits 320 Since both queries are doing INSERTs each must have an auto_increment ID created each ID must be attached to a new BTREE entry being written into the index In light of this, there has to be some lock engaged ...


0

Don't use a TRIGGER. Instead, gather a minute's worth (say) of data in a staging table. Then do the desired updates en masse. If you need the user to get up-to-the-second information (instead of just up-to-the-minute), have the user's query do that final update also. To phrase it differently, summarization is much more efficiently done in bulk. Your ...



Top 50 recent answers are included