How to achieve atomicity (all or nothing)?

Hey welcome! The short answer is that if you need shared state and you need to control changes to that state then yeah you would use an agent or GenServer (more generally) and put the state inside that.

In general though as a functional language much of your program design will be avoiding such shared state at all.

I understand that the functional style avoids shared states as much as possible. But shared states can’t be eliminated in many applications, like databases.

Suppose I have two tables in a database. I need to mutate both tables atomically in a transaction. How to achieve this in Elixir using Agent or GenServer?

One solution is to have an Agent manage both tables as one state. However, the downside is poor performance — when processA mutates table1 and processB mutates table2, the two mutations can’t be done in parallel, even if they are independent of each other.

I would simply use the database itself for this, it will provide a ton of dedicated tooling for it.

How do you make sure multiple actors changes are actually independent?

In the end you’ll surely get to the fact that immutability prevents certain optimizations, but generally the question should be how much those matter to the endproduct.

In the end you’ll surely get to the fact that immutability prevents certain optimizations, but generally the question should be how much those matter to the endproduct.

Good point.

How do you make sure multiple actors changes are actually independent?

Mutations of two tables seem surely independent. Can you provide an example?

Maybe someone wants to build a database in Elixir

Put each table in a separate process and they’re independent.

• Put the state inside a GenServer.
• Have it receive messages like :modify_twenty_things_inside_the_state.
• Modify stuff together in the message handler, to your heart’s content.
• ???
• Profit.

Or if a database need be involved, they have their own transaction primitives as others said.

The BEAM provides the infrastructure, but you need to write the code to glue things together into a consistent distributed system - and to be clear, once you have TWO GenServers you’re trying to make change together you’re in distributed-system territory.

For instance, here’s a very basic “table with a lock” GenServer (see below for notes):

defmodule TableWithLock do
  use GenServer

  defstruct [:data, :owner]

  def unlock(pid), do: GenServer.call(pid, :unlock)
  def lock(pid), do: GenServer.call(pid, :lock)
  def update(pid, fun), do: GenServer.call(pid, {:update, fun})

  @impl true
  def init(data) do
    {:ok, %__MODULE__{data: data, owner: nil}}
  end

  @impl true
  def handle_call(:lock, {pid, _tag}, state) do
    cond do
      is_nil(state.owner) ->
        # unlocked, pid now owns lock
        {:reply, :ok, %{state | owner: pid}}

      state.owner == pid ->
        # already locked by pid
        {:reply, :ok, state}

      true ->
        # locked by another process
        raise "oh no lock contention"
    end
  end

  def handle_call(:unlock, {pid, _tag}, state) do
    cond do
      is_nil(state.owner) ->
        # already not locked
        raise "somebody already unlocked this???"

      state.owner == pid ->
        # locked by the caller
        {:reply, :ok, %{state | owner: nil}}

      true ->
        # locked by somebody else
        raise "unlocking somebody else's lock"
    end
  end

  def handle_call({:update, fun}, {pid, _tag}, state) do
    cond do
      is_nil(state.owner) ->
        # not locked
        raise "not locked"

      state.owner == pid ->
        # locked by the caller
        result = fun.(state.data)
        {:reply, result, %{state | data: result}}

      true ->
        # locked by somebody else
        raise "updater not holding the lock"
    end
  end
end

{:ok, pid1} = GenServer.start_link(TableWithLock, [1,2,3])

:ok = TableWithLock.lock(pid1)

result = TableWithLock.update(pid1, fn data -> Enum.map(data, & &1*2) end)

:ok = TableWithLock.unlock(pid1)

IO.inspect(result)

There are a LOT of places where this could be work better / handle concurrency better:

• crashing the table when a second process tries to take the lock is not realistic. A better implementation would keep a queue of pids that are currently trying to take the lock in lock and pick the next one to reply to in unlock.
• crashing the table on bogus unlocks isn’t realistic either. An alternative would be to return something from handle_call that the implementation of unlock/1 could use to crash the calling process, since unlocking a table that you haven’t locked is a logic error
• if a process dies while holding the lock, it will never be unlocked. Tools like Process.monitor can help with this, at the cost of additional complexity.

Expanding this setup to TWO tables adds some extra complications:

• if process A takes lock 1 and then tries to take lock 2, while at the same time process B takes lock 2 and tries to take lock 1 the system is in a classic DEADLOCK situation. The default 5s timeout on GenServer.call will eventually pick a winner, but real systems will detect this and complain

• coordinating changes to ensure that they either all appear or all do not is still just as tricky as always. You’d need a third process to coordinate the TableWithLocks and roll back changes if a future change fails.

  Note that even the code in your example does not produce atomicity - if mutate2 returns false, the changes from mutate1 are still visible.

  Solving this problem correctly is capital-H Hard and the solutions are highly sensitive to exactly what tradeoffs your particular application can tolerate.

Really appreciate your comprehensive answer!