Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
Как красиво решить проблему с тупиковой ситуацией
|
|||
|---|---|---|---|
|
#18+
Транзакция выглядит так: Код: plaintext Код: plaintext Код: plaintext Как написано в мануале решение такое - Использовать условие FOR UPDATE OF при выполнении операции выбора. Какие ещё возможны варианты ? Как я понимаю лучше переписать транзакцию в виде одного оператора, чтобы уменьшить кол-во операций IO, кол-во операторов. Тогда работать будет быстрее и тупиковых ситуаций не будет. Только не могу понять как. Может кто подскажет решение ? Заранее спасибо. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.11.2007, 12:33 |
|
||
|
Как красиво решить проблему с тупиковой ситуацией
|
|||
|---|---|---|---|
|
#18+
Грустно получается. FOR UPDATE OF не проходит - 0511N WITH RS USE AND KEEP UPDATE LOCKS тоже не проходит - 0109N ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.11.2007, 13:33 |
|
||
|
Как красиво решить проблему с тупиковой ситуацией
|
|||
|---|---|---|---|
|
#18+
Опишите алгоритм более подробно, желательно на примере. id - generated у обеих таблиц? используется ли table1.id в insert в table2? как именно выглядит значение для table1.value в update? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.11.2007, 13:45 |
|
||
|
Как красиво решить проблему с тупиковой ситуацией
|
|||
|---|---|---|---|
|
#18+
Попробую полные SQL операторы для транзакции привести. Сначала вставляется строка: Код: plaintext 1. 2. 3. 4. Код: plaintext 1. Потом генерится сериализованный Java объект, который включает в состав объекта полученные ранее ID для новых записей таблиц BET и BETSELECTION. Как раз этот объект и записывается в VALUE. Объект генерится с помощью собственного алгоритма сериализации. Это и есть значение поля VALUE в таблице BET. Потом происходит апдейт блоба в таблице BET Код: plaintext 1. ID в обоих таблицах GENERATED ALWAYS AS IDENTITY Пример VALUE такой: x'1F8B08000000000000005BF39681B59C91B1B888412E393F57AF20312F29B5442F273F3D33590FC82AC9CC4BD7734A2D09F1EFFA2A72C458B9FB1B0F03434541392F030430F28388725604C55D0CE1F1C2781C420CACAEB9052595E59CDC0E2A106DE5A2420C42BE8E7EA18E3EF1018E91FEA121F13EFEC1AEE59C40D319455B2CDA7DCB191980EAA1B63080784C5C0CE5AC22601EAB284C504B8841FDD062430385102305EFCC9CDCFCBCD44A05BFCCE46C5E2E5E2E43532B230B05E7A2C4CAB4FCA214882FD5917C09640235E8256724E6A5A716EB3943688FFC9C94D4A2D4874B9C1D38C5AB21DEE58239840B6E392AC5C85857C46044A4D92ACE8925A9E9F94599A9C530738580D61431F065259625EAE50095EAB9E695E6224B169430303BB98654808381530016FCC84C6070B0F2D9373040820A844161080ED1D64A0711881B5550DC58940A7368706A625E726A707E695132AAAB0A19EA18584B18B89C1D7D7C9C5DFD42825CE1C6C330CC0EFB3B9030C6654749BE5E40517E416A5109D0E7C71A95366A1E14CA444D4F0CE0E0AC404E2AE08400E3550000A60AB390B0020000' Этого достаточно ? Если нет можно ещё примеры значений привести. Но из необычного только то что VALUE "особенный". ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.11.2007, 14:36 |
|
||
|
Как красиво решить проблему с тупиковой ситуацией
|
|||
|---|---|---|---|
|
#18+
Попробую полные SQL операторы для транзакции привести. Сначала вставляется строка: Код: plaintext 1. 2. 3. 4. Код: plaintext 1. Потом генерится сериализованный Java объект, который включает в состав объекта полученные ранее ID для новых записей таблиц BET и BETSELECTION. Как раз этот объект и записывается в VALUE. Объект генерится с помощью собственного алгоритма сериализации. Это и есть значение поля VALUE в таблице BET. Потом происходит апдейт блоба в таблице BET Код: plaintext 1. ID в обоих таблицах GENERATED ALWAYS AS IDENTITY Пример VALUE такой: x'1F8B08000000000000005BF39681B59C91B1B888412E393F57AF20312F29B5442F273F3D33590FC82AC9CC4BD7734A2D09F1EFFA2A72C458B9FB1B0F03434541392F030430F28388725604C55D0CE1F1C2781C420CACAEB9052595E59CDC0E2A106DE5A2420C42BE8E7EA18E3EF1018E91FEA121F13EFEC1AEE59C40D319455B2CDA7DCB191980EAA1B63080784C5C0CE5AC22601EAB284C504B8841FDD062430385102305EFCC9CDCFCBCD44A05BFCCE46C5E2E5E2E43532B230B05E7A2C4CAB4FCA214882FD5917C09640235E8256724E6A5A716EB3943688FFC9C94D4A2D4874B9C1D38C5AB21DEE58239840B6E392AC5C85857C46044A4D92ACE8925A9E9F94599A9C530738580D61431F065259625EAE50095EAB9E695E6224B169430303BB98654808381530016FCC84C6070B0F2D9373040820A844161080ED1D64A0711881B5550DC58940A7368706A625E726A707E695132AAAB0A19EA18584B18B89C1D7D7C9C5DFD42825CE1C6C330CC0EFB3B9030C6654749BE5E40517E416A5109D0E7C71A95366A1E14CA444D4F0CE0E0AC404E2AE08400E3550000A60AB390B0020000' Этого достаточно ? Если нет можно ещё примеры значений привести. Но из необычного только то что VALUE "особенный". ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.11.2007, 14:45 |
|
||
|
Как красиво решить проблему с тупиковой ситуацией
|
|||
|---|---|---|---|
|
#18+
2 инсерта вы еще сможете в один оператор объединить, а вот все 3 - нет. А где вы здесь дедлоки получаете в таком алгоритме? При выполнении UPDATE? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.11.2007, 15:19 |
|
||
|
Как красиво решить проблему с тупиковой ситуацией
|
|||
|---|---|---|---|
|
#18+
Да, deadlock при выполнении update. Но появляется очень редко. Только при нагрузочных тестах в определенной конфигурации, когда таблицы пустые. Когда в таблицах есть несколько тысяч записей, то deadlock нет. У нас Tomcat and DB2. Dealock появляется когда и то и другое стоит на одном сервере. Правильно ли я понял, Марк что единственным вариантом избавления от deadlock будет отказ от ID в BLOB ? Это решение реализуемо. Правда потребуется большой рефакторинг. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.11.2007, 22:49 |
|
||
|
Как красиво решить проблему с тупиковой ситуацией
|
|||
|---|---|---|---|
|
#18+
Денис, привет. А там эскалации блокировок на пустой таблице не происходит, случайно? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.11.2007, 13:05 |
|
||
|
|

start [/forum/topic.php?fid=43&tid=1604214]: |
0ms |
get settings: |
10ms |
get forum list: |
17ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
28ms |
get topic data: |
10ms |
get forum data: |
2ms |
get page messages: |
37ms |
get tp. blocked users: |
1ms |
| others: | 249ms |
| total: | 360ms |

| 0 / 0 |
