Ecto postgres database simultaneous update

Here are some options you can use to serialize access to rows. Regardless of which of these you use, I highly recommend also having a table that logs balance changes on each account, like a ledger. This allows you to audit the total in the future, and debug any issues.

Option 1: Avoid read, modify, write patterns.

Instead of doing:

account = Repo.get(Account, account_id)
account |> Account.changeset(%{balance: account.balance + 5}) |> Repo.update!

Do:

Account |> where(id: ^account_id) |> update(inc: [balance: 5]) |> Repo.update_all([])

In this approach, you change the balance in a single SQL query instead of two, avoiding race conditions. Postgres will ensure that the single update query runs atomicly.

Option 2: SELECT FOR UPDATE

If you can’t avoid read, modify, write, then take a lock on the row you wish to update:

Repo.transaction(fn ->
  account = Account |> lock("FOR UPDATE") |> Repo.get!(account_id)
  account |> Account.changeset(%{balance: account.balance + 5}) |> Repo.update!
end)

This locks access to the account row for the duration of the transaction, allowing your process to safely reason about it.

If conflict is rare, you can also try doing Ecto.Changeset — Ecto v3.14.0 instead.

Many thanks @benwilson512.

I think the option two will work for me.

It’s a high traffic application, using Elixir and ecto_sql with postgres.
There is usually multiples of requests to the same account.

For each request, I need to reduce the account balance by the requested value before taking an action, hence the need to do read, modify, and write on the record.

Kindly let me try it out and feedback on the outcome.

Regards,

Jerry

If you need just to update, then I think the 1st option will be better as you do not need to do 12 trips (at least as it is TCP) and you can just do everything in 6.

Hello @hauleth,

Considering the nature of the query statement in Option 2, does Option 1 give the same level of integrity to the data being modified?

Thanks.

Jerry

Yes, each query is transaction within itself, so within single query it is impossible to have race condition (assuming that there are no bugs in DB implementation). I would say that DB is probably better optimised for single UPDATE queries than locking mechanisms as second one can impose some additional restrictions as DB do not know what you want to do with that lock.

Thanks so much for the clarification, @hauleth.
I really appreciate it.

What does the below mean, please? especially, the inc

You can find more information here: Ecto.Query — Ecto v3.14.0

Thanks very much @benwilson512.
Information seen.

Kindly let me run the tests and then I’ll feedback on the results.

I’m grateful to you all for the assistance.

Regards,

Jerry

Hello,

I have another question, please.

Please pardon me if my question sounds too trivial.

Can I use a normal select query to retrieve the value of account_id in order to execute the query statement below?
How do I ensure that another process doesn’t retrieve that same value of account_id before getting to this stage of running the update statement?

Thanks.

If all you’re doing is grabbing the account id to then run this query, yes.

Why does this matter?