|
Сохранить в запись 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: |
15ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
47ms |
get topic data: |
12ms |
get forum data: |
2ms |
get page messages: |
48ms |
get tp. blocked users: |
2ms |
others: | 338ms |
total: | 479ms |
0 / 0 |