Hi There

Is active record 3.1.1 supposed to be threadsafe?
In other words, should the following (concurrent access to a model)
work?

Thread.new do MyModel.where(some_condition).first end
Thread.new do MyModel.where(some_condition).first end

I ask because upon the answer, it depends which component should handle
synchronization, and in consequence, which component to patch/fix.

A bit of background: We stumbled over a concurrency issue when using
capybara-webkit with rails3.1. We traced the issue down to one thread
querying and trying to accessing the cache while another thread cleared
the same cache.
Assuming active record 3.1.1 is supposed to be threadsafe, then the
culprit for the issue would be
ActiveRecord::ConnectionAdapters::QueryCache, which doesn't synchronize
access to its @query_cache. See
https://github.com/awd-switzerland/rails/commit/22aeda0f0553fdcabca156012b67f2aa2add293c
for a possible way to resolve that. However, I'm not sure in which layer
the rails team wants to handle synchronization.
Also notice that the patch is naive in that it simply assumes thread
support in ruby to be enabled.

Best regards
Stefan Rusterholz

--
Posted via http://www.ruby-forum.com/.

--
You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group.
To post to this group, send email to rubyonrails-talk@googlegroups.com.
To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.

Search Discussions

  • Frederick Cheung at Oct 28, 2011 at 1:40 pm

    On Oct 28, 10:02 am, AWD Switzerland wrote:
    Hi There

    Is active record 3.1.1 supposed to be threadsafe?
    In other words, should the following (concurrent access to a model)
    work?

    Thread.new do MyModel.where(some_condition).first end
    Thread.new do MyModel.where(some_condition).first end

    I ask because upon the answer, it depends which component should handle
    synchronization, and in consequence, which component to patch/fix.
    Rails added thread safety back in 2.1 or 2.2 so current versions
    should be threadsafe.
    A bit of background: We stumbled over a concurrency issue when using
    capybara-webkit with rails3.1. We traced the issue down to one thread
    querying and trying to accessing the cache while another thread cleared
    the same cache.
    Assuming active record 3.1.1 is supposed to be threadsafe, then the
    culprit for the issue would be
    ActiveRecord::ConnectionAdapters::QueryCache, which doesn't synchronize
    access to its @query_cache. Seehttps://github.com/awd-switzerland/rails/commit/22aeda0f0553fdcabca15...
    for a possible way to resolve that. However, I'm not sure in which layer
    the rails team wants to handle synchronisation.
    In theory I don't think this is needed because different threads
    should be using different connection objects (there's supposed to be a
    pool of connection objections, and any member of the pool is only ever
    used by one thread at a time. You might also want to ask on the rails-
    core list

    Fred
    Also notice that the patch is naive in that it simply assumes thread
    support in ruby to be enabled.
    Best regards
    Stefan Rusterholz

    --
    Posted viahttp://www.ruby-forum.com/.
    --
    You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group.
    To post to this group, send email to rubyonrails-talk@googlegroups.com.
    To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe@googlegroups.com.
    For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
  • AWD Switzerland at Oct 28, 2011 at 2:38 pm

    Frederick Cheung wrote in post #1028961:
    In theory I don't think this is needed because different threads
    should be using different connection objects (there's supposed to be a
    pool of connection objections, and any member of the pool is only ever
    used by one thread at a time. You might also want to ask on the rails-
    core list
    Seems practice disagrees with that theory. At least we had exceptions
    due to unsynchronized cache access. And we ourselves did not introduce
    any threads in the code.
    I'll see whether I get answers here. If not, I'll gladly accept your
    advice and take it on to rails-core.

    Best regards
    Stefan

    --
    Posted via http://www.ruby-forum.com/.

    --
    You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group.
    To post to this group, send email to rubyonrails-talk@googlegroups.com.
    To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe@googlegroups.com.
    For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
  • Frederick Cheung at Oct 28, 2011 at 8:25 pm

    On Oct 28, 3:38 pm, AWD Switzerland wrote:
    Frederick Cheung wrote in post #1028961:
    In theory I don't think this is needed because different threads
    should be using different connection objects (there's supposed to be a
    pool of connection objections, and any member of the pool is only ever
    used by one thread at a time. You might also want to ask on the rails-
    core list
    Seems practice disagrees with that theory. At least we had exceptions
    due to unsynchronized cache access. And we ourselves did not introduce
    any threads in the code.
    I'll see whether I get answers here. If not, I'll gladly accept your
    advice and take it on to rails-core.
    It might also be related to https://github.com/rails/rails/pull/1670

    Fred
    Best regards
    Stefan

    --
    Posted viahttp://www.ruby-forum.com/.
    --
    You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group.
    To post to this group, send email to rubyonrails-talk@googlegroups.com.
    To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe@googlegroups.com.
    For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouprubyonrails-talk @
categoriesrubyonrails
postedOct 28, '11 at 9:02a
activeOct 28, '11 at 8:25p
posts4
users2
websiterubyonrails.org
irc#RubyOnRails

People

Translate

site design / logo © 2022 Grokbase