Re: Logical locking beyond pg_advisory - Mailing list pgsql-general

From marcelo
Subject Re: Logical locking beyond pg_advisory
Date
Msg-id e3040ff1-0db0-c644-2ba2-0c7511fcb657@gmail.com
Whole thread Raw
In response to Re: Logical locking beyond pg_advisory  (Chris Travers <chris.travers@gmail.com>)
List pgsql-general


On 17/09/2018 14:27 , Chris Travers wrote:


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.

You are right. But you know...
 
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 by date:

Previous
From: Seamus Abshere
Date:
Subject: Too many BitmapAnds in the wild
Next
From: Tom Lane
Date:
Subject: Re: Too many BitmapAnds in the wild