Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
Сохранить в запись id предыдущей записи при конкурентном доступе
|
|||
|---|---|---|---|
|
#18+
У меня есть таблица events, в которой есть поля id и prev_id (которое является уникальным и ссылается на таблицу events). Поле prev_id нужно для того, чтобы программа могла построить очередь из событий. Для создания новой записи в events у меня используется следующая функция: Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. Но блокировка таблицы events в EXCLUSIVE MODE негативно сказывается на производительности приложения. Можно ли как-нибудь ее избежать? Я пробовал вариант последовательным Insert/Update, но он работает (Поле prev_id должно быть уникально, а появляются дубликаты): Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.01.2017, 13:07 |
|
||
|
Сохранить в запись id предыдущей записи при конкурентном доступе
|
|||
|---|---|---|---|
|
#18+
Я пробовал вариант последовательным Insert/Update, но он НЕ работает. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.01.2017, 13:17 |
|
||
|
Сохранить в запись id предыдущей записи при конкурентном доступе
|
|||
|---|---|---|---|
|
#18+
=MOHAX=, а id события нельзя заменить на сиквенс?? (sequence) тогда всякие локи не нужны будут, каждый INSERT в event будет возвращать новый уникальный id. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.01.2017, 14:12 |
|
||
|
Сохранить в запись id предыдущей записи при конкурентном доступе
|
|||
|---|---|---|---|
|
#18+
=MOHAX=, можно разгрузить чтение, лоча не таблицу, а строку в другой таблице, с единственным назначением--хранить достигнутое и быть ресурсом, к которому очередь. тогда чтение ивентов будет свободным, а запись -- строго в очередь. но, думаю, будут проблемы с параллельными транзакциями, в которых будет по несколько ивентов (надо протестить). вообще говоря поизучайте pgq -- организацию очереди и расчёт батча -- там почти без локов, но всё не так примитивно, как хотелось бы. я, в свое время порешал другую задачу -- из последовательно забираемых сиквенсов в т.ч. в параллельные транзы отследить максимальный, все меньшие которого закоммичены или ролбекнуты к настоящему моменту -- в дело не пошло, но работало чётко. хотя было собрано с использованием таких несинхронных штук, как pg_stat_activity. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.01.2017, 20:17 |
|
||
|
|

start [/forum/topic.php?fid=53&fpage=79&tid=1996736]: |
0ms |
get settings: |
9ms |
get forum list: |
12ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
38ms |
get topic data: |
14ms |
get forum data: |
4ms |
get page messages: |
41ms |
get tp. blocked users: |
1ms |
| others: | 286ms |
| total: | 411ms |

| 0 / 0 |
