Wrap all requests in transactions

danielgatis

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

7 comments

/phoenix #ecto

1 1515 7

2019-08-22 12:52:08 UTC

Showing Posts 1 to 7

Show Best Posts
Show All (oldest first)
Show All (newest first)

kokolegorille

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.

Post #1

danielgatis

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

Post #2

mbuhot

You could wrap all your controller actions in a Repo transaction by defining your own action plug: Phoenix.Controller — Phoenix v1.8.8

Post #3

danielgatis

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!

Post #4

nsweeting

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.

Post #5

Qqwy

TypeCheck Core Team

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).

Post #6

benwilson512

Author of Craft GraphQL APIs in Elixir with Absinthe

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.

Post #7

— All posts loaded —