A simple guide to pessimistic locking in Rails | Hacker News Reader

A simple guide to pessimistic locking in Rails

visuality.pl

65 pointsthunderbong13 comments

I don't think the last example about testing is correct:

    threads = []
    3.times do
      service.call
    end
    threads.each(&:join)

It probably intends to spin up the call in 3 separate threads and then wait on all of the threads as they do the work in parallel, but as written it will just do `service.call` three times in a row and then wait on zero threads.

more correct would probably be

  threads = []
  3.times.map do 
    Thread.new do 
      service.call
    end 
  end
  threads.each(&:join)

But whether or not multithreading is really available within the test setup, and also whether or not the database adapter runs via different connections is something that one wanted to validate.

That still wouldn't join any of the created threads though :)

Or this one?

  3.times.map do
   Thread.new do
     service.call
   end
  end.each(&:join)

I'm not really a fan of those & shortcuts.

> I'm not really a fan of those & shortcuts.

One of my favorite parts of ruby!

`collect.each(&:operation)` vs `collection.each { |thing| thing.operation }`

> &:operation

If one is unfamiliar, this syntax will implicitly call `Symbol#to_proc` on `:operation` and pass that as a block to the method (it will work with any object which responds to `#to_proc` and returns an object which responds to `#call`). These lines are all equivalent:

  my_array.map(&:operation)
  my_array.map { |my_element| my_element.operation }
  my_array.map { |my_element| :operation.to_proc.call(my_element) }

Given that, I adore the terseness in the first line, though I can understand a certain annoyance that the shorthand can cause if one doesn't know how this works.

I find it's best to just blindly accept it in Ruby, because you can really go down the rabbit hole otherwise. For example, the first example has even more syntactic fun going on because it looks like `map` accepts an argument but it doesn't:

    irb(main)> [1,2,3].map(1)
    (irb): in `map': wrong number of arguments (given 1, expected 0)

So you get clever and think.. well, it accepts a Proc, clearly, in the shape of &:operation. Let's use a Proc:

    irb(main)> [1,2,3].map(Proc.new { })
    (irb):in `map': wrong number of arguments (given 1, expected 0)

In the context of blocks, & is doing a little more than merely providing a Proc, but it's a handy way to think about it.

In the case of rails, using multiple threads will checkout extra database connections.

Database connections are often a limited resource though, so it is not without peril.

Well yes. That's how a connection pool works. You're not really supposed to be creating extra threads inside a request. Things can get wonky unless you know what you're doing. Best to use ActiveJob, which will have its own context even if it uses threads underneath.

That's still a no-op because `threads` is empty

  threads = 3.times.map do 
    Thread.new do 
      service.call
    end 
  end
  threads.each(&:join)

Guys, thank you for your comments, I'm the author of the blog post.

You are definitely right about the error in the last example about testing - I've added suggested ``` threads << Thread.new do service.call end ``` which we actually used in the project, but somehow omitted in the blogpost. On the other hand, I know it's quite a simplification and highly depends on the test env setup.

This is database dependent. For example SQLite does not support SELECT ... FOR UPDATE

of course, SQLite does not even lock rows, it locks the whole DB, only one writer. Most of the conversation in this article does not apply there.

Reply on news.ycombinator.com