DEV Community: Ivan Shamatov

Advisory locks (рекомендательные блокировки)

Ivan Shamatov — Mon, 27 Mar 2023 19:38:15 +0000

не путать с другими более оптимистичными или менее пессимистичными блокировками

Возможно у вас в проекте уже используются эти локи, но вы никогда не задумывались, что это за локи, как они работают и, самое важное, как НЕ работают.
Эта блокировка в качестве аргумента принимает строку, которая будет служить уникальным ключом.

Начнем с того, что лок делать НЕ умеет

1. Этот лок не блокирует данные, записи, таблицы, которые вы модифицируете внутри блока кода
Если у вас есть вот такой кусочек кода, который выполняется в потоке А

User.with_advisory_lock("updating_users_#{users.ids.join}") do
  users.where(role: "admin").update(role: "user")
end

и вот такой кусочек кода, который выполняется в потоке Б,

User.join(:permisson).where(permissions: { update: true }).update(role: "admin")

то поток Б может модифицировать данные, которые модифицирует поток А, и наоборот.

2. Нельзя заменить транзакцию локом.
Рекомендательные блокировки (в постгресе) так вообще игнорируют границы транзакции если запрос на уровне сессии. Чтобы получить эффект "все или ничего" нужно использовать транзакцию, даже если используешь и лок. Например, вот так:

User.transaction do
  User.with_advisory_lock("updating_user_#{user.id}") do
    user.update(role: "admin")
    user.user_organization.first.update_periods
  end
end

3. В общем случае, ключ для блокировок разных частей кода должен быть разным.
Вот два метода, и оба используют блокировку с одним и тем же ключом. Да, смотрится очень эффектно, но смысла в этом мало, потому как методы абсолютно независимые. Нет никакого резона, чтобы метод "update" ждал, пока метод "check" закончит свою работу, даже если он выполняется параллельно. И наоборот.

def update(users)
  with_user_lock do
    users.where(role: "admin").update(role: "user")
  end
end

def check(users)
  with_user_lock do
    users.all? { _1.task_completed? }
  end
end

def with_user_lock(user, &block)
  User.with_advisory_lock("updating_user_#{user.id}", &block)
end

Конечно, есть исключения и можно придумать сценарий, когда один и тот же лок в разных методах имеет смысл, но вы должны четко понимать, что вы делаете и зачем.

Так а зачем же тогда нужен этот лок?

Эта блокировка отлично подходит для контроля конкурентных запросов на уровне приложения (Application-level Concurrency Control). Это мьютекс, который используется для того, чтобы гарантировать, что два разных процесса, которые исполняют ОДИН и ТОТ ЖЕ код, не выполняют этот код одновременно.

class UpdateRoleJob < ApplicationJob
  def perform(user)
    User.with_advisory_lock("updating_user_#{user.id}") do
      user.update(role: "admin")
    end
  end
end

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

Каскадный rescue в ruby и в ActiveSupport::Rescuable

Ivan Shamatov — Sat, 11 Mar 2023 08:56:17 +0000

Возьмем пример

class E < StandardError; end

begin
  raise E
rescue E
  puts "here we rescue E"
rescue 
  puts "here we rescue StandardError"
end

Если вы используете вот такой вот каскадный rescue, то вы наверняка знаете, что сработает только обработчик первой ошибки, которая подпадает под условие.

=> here we rescue E
nil

Если мы повторно сделаем raise в обработке ошибки, то этот raise уже отловлен не будет и приведет к эксепшену

class E < StandardError; end

begin
  raise E
rescue E
  puts "here we rescue E"
  raise
rescue 
  puts "here we rescue StandardError"
end

=> here we rescue E
E: E
from (pry):27:in '__pry__'

rescue_from из ActiveSupport::Rescuable

Если мы захотим перенести такую логику в контроллер, или у нас есть какой-то кастомный бизнес-экшен, который использует ActiveSupport::Rescuable, то нужно помнить, что работать обработчик будет по-другому.

Пусть у нас будет вот такой базовый бизнес-экшн.

class Action
  include ActiveSupport::Rescuable

  def call
    call_impl
  rescue => ex
    rescue_with_handler(ex) or raise
  end
end

И мы наследуемся от него, определяя call_impl и добавляя обработчики ошибок,

class A < Action
  class E < StandardError; end

  rescue_from E do |ex|
    puts "here we rescue E"
    raise
  end

  rescue_from StandardError do |ex|
    puts "here we rescue StandardError"
  end

  def call_impl
    raise E
  end
end

то получим вот такой результат.

> A.new.call
here we rescue StandardError
=> #<A::E: A::E>

Дело в том, что rescue_from работает в FILO режиме (First In Last Out), то есть последний обработчик, который мы определили, будет первым попробованным.

Поменяем местами обработчики местами

class A < Action
  class E < StandardError; end

  rescue_from StandardError do |ex|
    puts "here we rescue StandardError"
  end

  rescue_from E do |ex|
    puts "here we rescue E"
    raise
  end

  def call_impl
    raise E
  end
end

и вот результат

irb(main):044:0> A.new.call
here we rescue E
Traceback (most recent call last):
...
1: from (irb):41:in `call_impl'
A::E (A::E)

Таким образом мы видим, что сработал именно обработчик ошибки A::E, а не StandardError, а так же, что raise внутри обработчика ошибки не привел к еще повторному rescue из StandardError.

dry-cli v0.6. Highlighting main features

Ivan Shamatov — Fri, 06 Mar 2020 10:57:24 +0000

Hey folks!
For those who are not familiar with dry-cli gem, let me introduce it to you. Long story short: dry-cli, formerly known as hanami-cli, was moved from hanami repository to dry-rb organization. For almost everyone, hanami-cli sounds like a set of cli utilities/generators/runners for hanami, but in fact it wasn't the case.

So it was decided to rename hanami-cli to dry-cli. hanami-cli 0.3.1 became a dry-cli 0.4, dry-cli 0.5 release removed all the hanami dependencies. And the latest release of dry-cli 0.6 has multiple new features. Do not worry, all backward compatibility is retained.

So let me run through the CHANGELOG and highlight some of the new features.

Anonymous registry syntax
Singular command app
Inline syntax for commands
Stderr added

Anonymous registry syntax

Initial hanami-cli allowed to create any module you want, extend it with Dry::CLI::Registry functionality and use register method to add commands inside.

module Commands
  extend Dry::CLI::Registry

  register 'version', Version, aliases: %w[v -v --version]
  register 'echo',    Echo

  register 'generate', aliases: ['g'] do |prefix|
    prefix.register 'config', Generate::Configuration
  end
end

Dry::CLI.new(Commands).call

Please understand me correctly, I love Registry concept, but to decrease entry threshold the new anonymous registry syntax has been introduced. Now you don't have to think of an extra Registry module, it will be prepared for you automatically at runtime.

  Dry.CLI do
    register 'version', Version, aliases: %w[v -v --version]
    register 'echo',    Echo

    register 'generate', aliases: ['g'] do
      register 'config', Generate::Configuration
    end
  end.call # do not forget to execute `call` after configuring your CLI

Singular command app

You can think of 2 types of CLI applications:

Single command, like ls, cat, cd
Multitool, like git or heroku.

So when you invoke git you also have to specify which command of git do you need to run: git pull, git checkout, etc. For a long time, hanami-cli (and later dry-cli) was extremely useful for building multitools, but you had no ability to create a single command app.

Now it is fixed. And to run a singular command app you may pass the command-class into Dry.CLI constructor.

class Command < Dry::CLI::Command
  def call(**options)
  end
end

Dry.CLI(Command).call

Inline syntax for commands

I decided to go further and added a little bit of syntactic sugar. Think of it as something similar to the sinatra simplified syntax.

require 'sinatra'

get '/' do
  'Hello world!'
end

and you still can make a separate class and run it:

require 'sinatra/base'

class App < Sinatra::Base
  get '/' do
    'Hello world!'
  end
end

App.run!

Similarly to sinatra, you have the ability to save some keystrokes with dry-cli, while building a very simple CLI app. And with a combination of bundler inline syntax it looks awesome:

#!/usr/bin/env ruby
require 'bundler/inline'

gemfile { gem 'dry-cli', require 'dry/cli/inline' }

desc 'List files in a directory'
argument :path, required: false, desc: '[DIR]'
option :all, aliases: ['a'], type: :boolean

run do |path: '.', **options|
  puts options.key?(:all) ? Dir.entries(path) : Dir.children(path)
end

Don't forget to run chmod +x your_cli to be able to execute it.

Stderr added

Nothing to show here, just a small improvement according to the best Unix's practices. All the diagnostic outputs and errors should go straight to the Stderr. The banner which reacts to the -h flag is the result of command execution, so the output is valid and goes straight to the Stdout.

Future plans

Since I've joined the team to work on this gem, I found lots of things to improve.

First of all, currently all the IO inside the commands are not being delegated to IO you pass into Dry.CLI constructor.
I'm looking for a better way to invoke commands from the other commands
Several file utils have been extracted from hanami to be a part of the dry-cli gem. We need a better support for them.
Generation abilities (https://github.com/dry-rb/dry-cli/pull/38)
Add support for subcommands with valid parent command (https://github.com/dry-rb/dry-cli/pull/86)