[HN Gopher] A simple guide to pessimistic locking in Rails
___________________________________________________________________
A simple guide to pessimistic locking in Rails
Author : thunderbong
Score : 63 points
Date : 2023-06-26 15:00 UTC (1 days ago)
(HTM) web link (www.visuality.pl)
(TXT) w3m dump (www.visuality.pl)
| WJW wrote:
| 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.
| radiospiel wrote:
| 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.
| yxhuvud wrote:
| 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.
| kayodelycaon wrote:
| 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.
| WJW wrote:
| That still wouldn't join any of the created threads though :)
| rco8786 wrote:
| 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)
| pmontra wrote:
| 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.
| rco8786 wrote:
| > 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 }`
| lcnPylGDnU4H9OF wrote:
| > &: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.
| steve_gh wrote:
| This is database dependent. For example SQLite does not support
| SELECT ... FOR UPDATE
| why-el wrote:
| 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.
___________________________________________________________________
(page generated 2023-06-27 23:02 UTC)