|
deadlocks
|
|||
---|---|---|---|
#18+
вот deadlock Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20.
проблема получается в тригере uTranchePerf_trg. Вот текст тригера: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24.
Посоветуйте что можно зделать чтобы предотврать появления deadlock. Может на уровне тригера чтото надо менять. Если нужна ище какаито инфа спрашивайте, спасибо ... |
|||
:
Нравится:
Не нравится:
|
|||
24.11.2010, 15:54 |
|
deadlocks
|
|||
---|---|---|---|
#18+
On 24.11.2010 15:54, gda wrote: > Посоветуйте что можно зделать чтобы предотврать появления deadlock. Может на > уровне тригера чтото надо менять. Если нужна ище какаито инфа спрашивайте, спасибо Как водится, дедлок не возникает в одном процессе. Их нужно как минимум 2. Поэтому хотелось бы знать, что делал в этот момент другой процесс. Posted via ActualForum NNTP Server 1.4 ... |
|||
:
Нравится:
Не нравится:
|
|||
24.11.2010, 16:58 |
|
deadlocks
|
|||
---|---|---|---|
#18+
On 24.11.2010 15:54, gda wrote: > Deadlock Id*144*: Process (Familyid*0*, Spid*452*) was waitingfor a'exclusive intent' lock on the'tranche_master' table in database*21* but process (Familyid*0*, Spid*171*) already held a'shared intent' lock on it. > Deadlock Id*144*: Process (Familyid*0*, Spid*452*) was chosenas the victim.End of deadlock information. > Посоветуйте что можно зделать чтобы предотврать появления deadlock. Может на А часто возникает ? Сколько раз в день ? Просто там наполовину на системных локах дедлок. Posted via ActualForum NNTP Server 1.4 ... |
|||
:
Нравится:
Не нравится:
|
|||
24.11.2010, 17:01 |
|
deadlocks
|
|||
---|---|---|---|
#18+
често не знаю сколько раз ... ... |
|||
:
Нравится:
Не нравится:
|
|||
24.11.2010, 17:49 |
|
deadlocks
|
|||
---|---|---|---|
#18+
On 24.11.2010 17:49, gda wrote: > често не знаю сколько раз ... Так считай. Если раз в пятелетку, то ничего делать не надо. deadlock-и в принципе неизбежны в любой системе. Если они совсем не мешают, то бороться с ними -- это всё равно, что реку ковшиком вверх по течению носить и выливать. Если не знаешь, сколько раз случается, то наверное оно не часто, иначе знал бы от пользователей. А коли так, и делать ничего не надо. Posted via ActualForum NNTP Server 1.4 ... |
|||
:
Нравится:
Не нравится:
|
|||
24.11.2010, 19:01 |
|
deadlocks
|
|||
---|---|---|---|
#18+
Согласен с MasterZiv, с маленьким дополнением. Возможно, на стороне клиента можно прозрачно для пользователя повесить обработку сообщения о deadlock, выполнить реконнект и заново попробовать выполнить транзакцию. ... |
|||
:
Нравится:
Не нравится:
|
|||
24.11.2010, 23:27 |
|
deadlocks
|
|||
---|---|---|---|
#18+
to kolchanov, так оно и было попросил чтобы попробовал ище раз, проблема исчезла ... |
|||
:
Нравится:
Не нравится:
|
|||
25.11.2010, 09:45 |
|
deadlocks
|
|||
---|---|---|---|
#18+
On 25.11.2010 9:45, gda wrote: > так оно и было попросил чтобы попробовал ище раз, проблема исчезла Три вещи, которые ты должен понимать на предмет dealdock-ов. они неизбежны в многопользовательских системах. В частности, в СУБД. возникновение их СЛУЧАЙНО. приложение ВСЕГДА должно быть готово к их появлению, оно ОБЯЗАНО повторить транзакцию ещё раз. Posted via ActualForum NNTP Server 1.4 ... |
|||
:
Нравится:
Не нравится:
|
|||
25.11.2010, 10:48 |
|
deadlocks
|
|||
---|---|---|---|
#18+
авторприложение ВСЕГДА должно быть готово к их появлению, оно ОБЯЗАНО повторить транзакцию ещё раз. как это сделать в моем случаи ... |
|||
:
Нравится:
Не нравится:
|
|||
25.11.2010, 11:29 |
|
|
start [/forum/topic.php?fid=55&tid=2010464]: |
0ms |
get settings: |
11ms |
get forum list: |
16ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
52ms |
get topic data: |
13ms |
get forum data: |
3ms |
get page messages: |
48ms |
get tp. blocked users: |
2ms |
others: | 16ms |
total: | 169ms |
0 / 0 |