How many of these processes do you expect to have running concurrently? How
long does that API call take? Might it be better to update the customer (or
in a separate table as suggested) as "catch up charge process started at"
and then clear that or set completed time in another column to
Hey Nick,
Thanks! Yep that’s an alternative (together with a uniqueness constraint
and retry mechanism)
I guess what I’m trying to get my head around is whether and why this would
be better than using advisory locks…
Cheers
Perryn
On Thu, 14 Apr 2022 at 10:32 pm, Nick Cleaton wrote:
> On
On Thu, 14 Apr 2022 at 10:47, Steve Baldwin wrote:
> Ok, so you want to allow _other_ updates to a customer while this process
> is happening? In that case, advisory locks will probably work. The only
> consideration is that the 'id' is a bigint. If your customer id maps to
> that, great. If not
Ok, so you want to allow _other_ updates to a customer while this process
is happening? In that case, advisory locks will probably work. The only
consideration is that the 'id' is a bigint. If your customer id maps to
that, great. If not (for example we use UUID's), you will need some way to
Hi Steve,
Thanks for your thoughts!
I was thinking to avoid using locks on the customer rows because there is a
lot of other unrelated access to that table. In particular I don’t want
writes to that table queueing up behind this process.
However, does the fact that you are suggesting row locks
Hi Perryn,
I don't know why you think advisory locks are the solution. It seems
regular row locks would ensure you have exclusive access to the customer.
Maybe something like this:
begin;
select * from customer where id = $1 for update skip locked;
if the query returns no rows it means
Hi there,
We have identified a problem that we think advisory locks could help with,
but we wanted to get some advice on whether its a good idea to use them
this way (and any tips, best practices or gotchas we should know about)
THE PROBLEM
We have some code that does the following
- For
