Re: Logical locking beyond pg_advisory
От | Chris Travers |
---|---|
Тема | Re: Logical locking beyond pg_advisory |
Дата | |
Msg-id | CAKt_ZfvMMCOGMVaYRRVnceU2S=rKzCZ3irDF+f9+WpjX3_nwDg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Logical locking beyond pg_advisory (marcelo <marcelo.nicolet@gmail.com>) |
Ответы |
Re: Logical locking beyond pg_advisory
|
Список | pgsql-general |
On Mon, Sep 17, 2018 at 6:04 PM marcelo <marcelo.nicolet@gmail.com> wrote:
I´m using an ORM (Devart´s) to access the database, so, I cannot "select ... FOR UPDATE". The application paradigm is that a user have a list of records (after a query) and she could update or delete any of them as the business rules allows it. So, at least an advisory lock is a must.
I´m convinced by now: I would stay with advisory locks... expecting no app crash could occur...
I would say to fix this in the ORM rather than reinvent what the database already gives you in the database.
Best Wishes,
Chris Travers
Efficito: Hosted Accounting and ERP. Robust and Flexible. No vendor lock-in.
В списке pgsql-general по дате отправления: