переопределить обратные вызовы activerecord для их асинхронного запуска

Question

Я работаю над приложением rails, и в настоящее время мы переходим на jruby.в настоящее время у нас более 10 после обратных вызовов для одной из наших моделей, и это блокирует ответ на долгое время.

after_update :sync
after_update :send
after_create :add
after_create :add
after_create :send
after_update :track!
after_create :track!
after_create :send_welcome_email
after_create :track
after_update :send
after_update :set_is_active!
after_update :set_
after_create :apply
after_update :apply
after_update :clear
after_create :mark

мне нужно обернуть / переопределить обратные вызовы activerecord after (after_save, after_update) для их запускаасинхронно использует concurrent-ruby, чтобы не блокировать ответ, но я не знаю, как сделать это правильно.

что я хочу сделать, это что-то вроде

require 'concurrent'
class ApplicationRecord < ActiveRecord::Base
  def after_update
    Concurrent::Promise.new { super }.exec
  end
end

я простонужно знать правильный синтаксис и правильный ли это подход для чего-то подобного.Буду признателен за любые предложения.

Answer 1

здесь нет общего совета - нужно немного знать о приложении.

несколько вещей, о которых нужно знать:

• звучит так, как будто вы вад обратного вызова, может быть, немного переосмыслить архитектуру - уменьшить эти модели и / или использовать наблюдателей (для упрощения)

• вы, конечно, можете перенести выполнение в другой поток, но после действий лучше независит от состояния друг друга

• также, если те, кто после частей выполняют операции БД, знают о запуске их вне «основной» транзакции

• последняя, ​​ноНе в последнюю очередь не забудьте выполнить очистку - AR-соединения должны быть возвращены в пул, поскольку Rails не сделает этого за вас (как с потоками запросов), если вы явно не укажете это

в общем, что делать с этим: если вам нужно ждать завершения и ваши обратные вызовы должны выполняться последовательно, перемещение их в другой поток не будет иметь большого эффекта.если это не так, попробуйте это и, возможно, подумайте, хотите ли вы, чтобы все обещания выполнялись на одном и том же (по умолчанию) исполнителе, или хотите явно определить разные (например, для задач с интенсивным использованием ЦП или задач, связанных с вводом-выводом).