Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
DB2: legacy app
|
|||
|---|---|---|---|
|
#18+
день добрый, DBAs. Имеем ситуацию -- в одном банке есть legacy приложение, которое, понятно, процессит денежки. Приложение это написано на Java (а ранее было написано на C), а моя задача -- дописывая и переписывая функциональность по кусочку, постепенно снять его с эксплуатации, поскольку с поддержкой большие проблемы. Дописываемая функциональность живет в отдельном приложении, в другом процессе, на другом сервере. При этом дописывать нужно по возможности поверх существующей DB schema, и крайне нежелательно трогать что-либо в legacy (хотя и возможно) -- нет regression tests. Итак, проблема -- для функциональности, которую я сейчас разрабатываю, необходимо создавать записи в существующей таблице. В таблице есть суррогатный primary key, который мне при вставке записи необходимо сгенерить (там не используются IDENTITY и SEQUENCE ввиду древности приложения). Ключ в legacy приложении генерится так -- существует таблица вида ( name varchar(30), max_id integer ), которой делается 1. SELECT max_id from ... where name='tableName' 2. increment max_id 3. UPDATE ... SET max_id = ... where name='tableName' Для пущей важности всё это еще обложено Java synchronized, чтобы избежать duplicate key. Мне надо определиться, как я буду генерить ключи. До сего момента я думал, что буду делать SELECT ... FOR UPDATE, полагаясь на блокировки DB2. Однако, попробовав на макете, понял, что это не работает. Legacy делает свой select в READ COMMITTED transaction, и в ситуации: Код: plaintext 1. 2. 3. 4. 5. получаем duplicate key в legacy и у меня. Попробовал выставить себе FOR UPDATE WITH RS USE AND KEEP UPDATE LOCKS Не особо помогает. Всё равно существует ситуация, когда мы получаем равные ключи. Подъем моей транзакции до SERIALIZED также не помогает. Работает только вариант, когда исходный код legacy подправлен на предмет добавления FOR UPDATE WITH RS USE AND KEEP UPDATE LOCKS. В этом случае дубликатов нет, но появляются deadlocks (кто бы сомневался). Скажите мне -- существует ли способ залочить таблицу или запись так, чтобы а) если кто-то выполнил SELECT на таблице, то мой лок ждал бы его COMMIT'а? б) если я получил лок, то никто не смог бы сделать SELECT до моего COMMIT? P.S. думал переписать таки legacy под SEQUENCES, но -- страшно, и они в одном месте выделяют сразу пачку ID, что с SEQUENCES, AFAIK, невозможно? P.P.S. DB2 8.x (8.1?) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.06.2005, 20:18 |
|
||
|
DB2: legacy app
|
|||
|---|---|---|---|
|
#18+
Vladimir Dyuzhevдень добрый, DBAs. ... Скажите мне -- существует ли способ залочить таблицу или запись так, чтобы а) если кто-то выполнил SELECT на таблице, то мой лок ждал бы его COMMIT'а? б) если я получил лок, то никто не смог бы сделать SELECT до моего COMMIT? P.S. думал переписать таки legacy под SEQUENCES, но -- страшно, и они в одном месте выделяют сразу пачку ID, что с SEQUENCES, AFAIK, невозможно? P.P.S. DB2 8.x (8.1?) перед селектом: lock table ... in exclusive mode ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.06.2005, 11:03 |
|
||
|
DB2: legacy app
|
|||
|---|---|---|---|
|
#18+
и неясно про sequence и выделение пачкой. Это не то, что в sequence делает кэширование ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.06.2005, 11:49 |
|
||
|
DB2: legacy app
|
|||
|---|---|---|---|
|
#18+
Какая версия DB2??? В 8-ке можно сделать следующее То что имеешь ты в lеgacy приложении Получить № следующего заказа Код: plaintext 1. Код: plaintext 1. 2. Код: plaintext 1. Имеем Deadlock, 3 SQL оператора, 3 I/O, одна строка OLTP Mantra гласит Уменьшение кол-ва вызовов (Reduce Codepath) Уменьшение Logical I/O Уменьшение Physical I/O Минимизация влияния блокировок Избежание Deadlocks Код: plaintext 1. 2. 3. 4. 5. 6. 7. Если можно было бы делать sequence, то было бы можно сделать проще Код: plaintext 1. 2. 3. 4. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.06.2005, 13:23 |
|
||
|
DB2: legacy app
|
|||
|---|---|---|---|
|
#18+
Alexander Mozhaev перед селектом: lock table ... in exclusive mode не, не получается. вот обломившийся сценарий: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. слева -- legacy, справа -- я. то есть -- legacy начинает транзакцию, делает выборку, потом я начинаю транзакцию, накладываю лок, legacy инкрементит и пытается обновить, но повисает, я вытаскиваю текущее значение -- а оно всё еще 20 -- увеличиваю, коммичу, освобождая тем самым таблицу, и после этого успешно проходит коммит от legacy. результат -- оба имеем ID=21. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.06.2005, 17:31 |
|
||
|
DB2: legacy app
|
|||
|---|---|---|---|
|
#18+
чтобы точно показать, что я там делаю: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.06.2005, 17:36 |
|
||
|
DB2: legacy app
|
|||
|---|---|---|---|
|
#18+
ggv и неясно про sequence и выделение пачкой. Это не то, что в sequence делает кэширование Не, это возможность прирастить счетчик за один вызов на N единиц, причем так, чтобы никто не вклинился в середину. Т.е. UPDATE ... SET ID = ID+10, например. Legacy использует это для одного своего загадочного модуля, и пока неясно, необходимо ли иметь строго непрерывные ID, или это просто деталь реализации. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.06.2005, 17:40 |
|
||
|
DB2: legacy app
|
|||
|---|---|---|---|
|
#18+
nkulikov Какая версия DB2??? В 8-ке можно сделать следующее Да, 8. nkulikov Код: plaintext 1. 2. 3. 4. 5. 6. 7. Ух! Это пока за пределами моего понимания. Что тут происходит? Я вообще не врубаюсь, какие-такие OLD TABLE, NEW TABLE... :( Я адаптировал эту китайскую грамоту для моего теста, и получилось вот что: Код: plaintext 1. 2. Этот код должен выполняться на моей стороне? Или на обоих? Явные блокировки нужны? Исполнение в Control Center приводит к выводу текущего значения, но не к обновлению такового... что я делаю не так? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.06.2005, 17:51 |
|
||
|
DB2: legacy app
|
|||
|---|---|---|---|
|
#18+
ну insert в conflict тебе наверное не нужен а чтоб понят это предложение попроси у Николая презентацию "Unleashed SQL" Ну или читать доку ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.06.2005, 17:55 |
|
||
|
DB2: legacy app
|
|||
|---|---|---|---|
|
#18+
nkulikov WITH inco AS (SELECT ordernum ... Наконец-то до меня дошло. Вот моя новая адаптация, которая работает просто perfectly. Код: plaintext 1. Я так понимаю, её надо гонять на обоих сторонах -- и на legacy, и на replacer app. Ну... не хотелось менять legacy code, но, видать этого не избежать. Инкремент в один запрос сильно упрощает тамошний код, а то, что нет deadlocks (я проверил -- прогнал 70 возможных сценариев ;) ) -- вообще замечательно. Искреннее нечеловеческое спасибо. Будем внедрять. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.06.2005, 18:17 |
|
||
|
DB2: legacy app
|
|||
|---|---|---|---|
|
#18+
Все таки я выложу эту презентацию на www.idug.ru что бы все не рассылать, несколко вырезок из нее OLD TABLE промежуточная таблица как в триггерах Для DELETE UPDATE Просмотр оригинальных значения перед модификацией Код: plaintext 1. NEW TABLE промежуточная таблица как в триггерах Для INSERT UPDATE Можно просмотреть Значения вычисленные пользователем IDENTITY Что выставил триггер BEFORE Генерируемые столбцы Код: plaintext 1. FINAL TABLE Содержимое после проверки RI и отработки AFTER триггера Не разрешаются конфликты на изменяющейся (mutating) Талице Пример 2 Таблицы Emp и Mgr Транзакция повышение сотрудника 1) Удалить из сотрудников (Delete Emp) 2) Вставить в таблицу менеджеры (Insert Mgr) 2) Увеличить зарплату по умолчанию 4) Назначить бонус через триггер Код: 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. 25. 26. 27. 28. 29. 30. 31. 32. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.06.2005, 18:55 |
|
||
|
DB2: legacy app
|
|||
|---|---|---|---|
|
#18+
Так - между прочим... 1) Реализовать аналог SEQUENCE элементарно в любой версии DB2 с помощью хранимых процедур. 2) При таком подходе можно также получать сразу пачку уникальных значений. (Хотя я полагаю с SEQUENCE такое тоже возможно) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.06.2005, 11:57 |
|
||
|
DB2: legacy app
|
|||
|---|---|---|---|
|
#18+
nkulikovВсе таки я выложу эту презентацию на www.idug.ru что бы все не рассылать, Выложил или забыл? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.10.2006, 06:37 |
|
||
|
|

start [/forum/topic.php?fid=43&msg=33110358&tid=1605084]: |
0ms |
get settings: |
8ms |
get forum list: |
16ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
71ms |
get topic data: |
7ms |
get forum data: |
2ms |
get page messages: |
31ms |
get tp. blocked users: |
1ms |
| others: | 250ms |
| total: | 394ms |

| 0 / 0 |
