Wrap all requests in transactions

Phoenix Forum Questions / Help
,
1

Is it possible to set up a Phoenix application such that all controller actions are automatically wrapped with a transaction, that gets automatically rolled back in case of unrescued exceptions?

In ruby I used to do this like the following:

require 'activerecord'

class TransactionalRequests
  def initialize(app)
    @app = app
  end

  def call(env)
    ActiveRecord::Base.transaction do
      @app.call(env)
    end
  end
end
1 Like
2

Hello and welcome,

Ecto has support for transactions.

It is also possible to use Ecto Multi and it is possible to wrap multiple operations inside a transaction. As there is no callback, it is used to perform
 multiple operations.

But Ecto is not Active Record, it uses the Repo pattern.

And controller actions usually call contexts functions.

1 Like
3

I know but what happens if my controller call two context function each one with your own transaction?

In my context.

def func1(...) do
   Repo.transaction(fn ->
     ...
   end)
end

def func2(...) do
   Repo.transaction(fn ->
     ...
   end)
end

In my controller

def create( ..) do
   Context.func1() #-> commited.
   Context.func2() #-> exception here
   ...
end
4

You could wrap all your controller actions in a Repo transaction by defining your own action plug: https://hexdocs.pm/phoenix/Phoenix.Controller.html#module-overriding-action-2-for-custom-arguments

2 Likes
5

nice! thanks guys.

In my controller

  def action(conn, _) do
    args = [conn, conn.params]
    with {_, response} <- Repo.transaction(fn -> apply(__MODULE__, action_name(conn), args) end) do
      response
    end
  end

Works perfect!

2 Likes
6

It would be a better pattern if your web layer simply called a “context” function that wrapped both function calls in a transaction. Improves visibility of what is actually occuring instead of hiding it within a plug. Plus makes testing easier.

3 Likes
7

In that case, you should probably have a single (maybe a third) context that takes care of what these two functions do. Which again could wrap both of them in another Repo.transaction(fn -> ... end).

When working with MVP/BDD, controllers really can strive to only have the single responsibility of ‘being a traffic cop’: Doing some preliminary checking of input parameters (and things like “is the user logged in?”) and then redirecting to the appropriate context(s).

8

The main thing to watch out for now is that your controller actions need to avoid doing non-database IO. If you make requests to external services that take several hundred ms for example, your request will be hogging the database connection for that time while not really using it.

2 Likes