ëÁÞÁÎÏ×ÓËÉÊ äÍÉÔÒÉÊ wrote:
Ну вот опять, сначала написал, а потом понял что снова поторопился... опять
неправильно поймут :)
вот эту строчку
2. (wait) дождаться когда будет можно и выполнить
правильно читать так
2. (wait) дождаться когда будет можно будет выполнить операцию над всем
множеством (естественно не блокируя его на время ожидания) и выполнить
это было понятно, но чего ты этим хочешь добится? в общем случае
проблему deadlock ты не решил, поскольку в одной транзакции можно
использовать несколько update. ну да, в твоем конкретном случаее это бы
решило твою проблему _если_ сразу после update сделать commit. если
этого не сделать, то на deadlock ты нарвешся в каком-то другом update.
так что единственное, что тебе поможет - заблокировать записи _в начале_
транзакции (это должен быть действительно самый первый оператор в
транзакции), а уже потом делать update. это так называемый two-phase
locking.
если ты не в курсе, то у нас update some_table set pk = pk + 1 приведет
к нарушению уникальности ключа (а в других серверах - нет), а это более
серьезная проблема чем твоя, но ее еще не решили, поскольку не все так
тривиально.
так что ответ на твой вопрос: "да, было бы логичнее, но нет, пока все
остается так как было да и проблему твою решать надо по другому".
Роман
