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.

 
Thank you all.
Marcelo

Libre de virus. www.avast.com


--
Best Wishes,
Chris Travers

Efficito:  Hosted Accounting and ERP.  Robust and Flexible.  No vendor lock-in.

В списке pgsql-general по дате отправления:

Предыдущее
От: Dimitri Maziuk
Дата:
Сообщение: Re: Code of Conduct plan
Следующее
От: Ben Uphoff
Дата:
Сообщение: Why is JSONB field automatically cast as TEXT?