| Commit message (Collapse) | Author | Age | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Fixes #336
There was an occasional deadlock when two emails for the
same request came in near-simultaneously; two processes
would be started via script/mailin, each to deal with one
email which are both updating the same InfoRequest.
The error would look like:
2013-04-07 09:19:03 BST [13398]: [2-1] DETAIL: Process 13398 waits for ShareLock on transaction 36193647; blocked by process 13397.
Process 13397 waits for ExclusiveLock on tuple (390,35) of relation 32918788 of database 32918687; blocked by process 13398.
Process 13398: UPDATE "info_requests" SET "updated_at" = '2013-04-07 08:19:02.139515', "awaiting_description" = 't' WHERE "id" = 156200
Process 13397: UPDATE "info_requests" SET "updated_at" = '2013-04-07 08:19:02.143624', "awaiting_description" = 't' WHERE "id" = 156200
This arose from the following section of code:
ActiveRecord::Base.transaction do
raw_email = RawEmail.new
incoming_message.raw_email = raw_email
incoming_message.info_request = self
incoming_message.save!
raw_email.data = raw_email_data
raw_email.save!
self.awaiting_description = true
params = { :incoming_message_id => incoming_message.id }
if !rejected_reason.empty?
params[:rejected_reason] = rejected_reason.to_str
end
self.log_event("response", params)
self.save!
end
Matthew Somerville explained what was happening here in the
issue report; to repeat his explanation from the bug report,
both processes enter the transaction block and acquire a
ShareLock on self with:
incoming_message.info_request = self
incoming_message.save!
However, in order to update the self.awaiting_description field
of the InfoRequest, with:
self.awaiting_description = true
[...]
self.save!
... the ShareLock needs to be upgraded to an ExclusiveLock,
but both will wait until the other's ShareLock is released,
which would only happen at the end of the transaction.
We can avoid this deadlock by using SELECT ... FOR UPDATE
for the row in info_requests. In Rails 3.2.0 there is
ActiveRecord support for this (via with_lock and lock! on
a model instance) but so as not to require upgrading rails,
I'm just using raw SQL.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|\ |
|
| | |
|
| |
| |
| |
| | |
underlying method as other slug generation. Fixes #567.
|
|/ |
|
|\ |
|
| | |
|
|/
|
|
| |
attribute instead of a full user model. Fixes #715.
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
that the method can return a value cached on the object by a previous call.
|
|
|
|
| |
prominence
|
| |
|
| |
|
|\ |
|
| |
| |
| |
| | |
days) configurable
|
| | |
|
| | |
|
|/
|
|
| |
Closes #30.
|
|
|
|
| |
be used in conjunction with pagination.
|
|
|
|
| |
bodies.
|
|
|
|
| |
and random sets of small numbers of old unclassified requests.
|
|\
| |
| |
| |
| |
| |
| |
| | |
Conflicts:
app/controllers/admin_public_body_controller.rb
app/views/admin_public_body/import_csv.rhtml
spec/controllers/admin_public_body_controller_spec.rb
spec/models/info_request_spec.rb
|
| | |
|
| |
| |
| |
| | |
apply rules from its public body.
|
| |
| |
| |
| | |
Apply global rules to every request, not regex rules.
|
| |
| |
| |
| |
| |
| |
| | |
If someone reports an external request as needing administrator
attention, we should email the administrators about it.
Thanks for spotting this, @crowbot.
|
| |
| |
| |
| | |
Closes #554.
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Also make the InfoRequest#is_old_unclassified? method a little
more conservative, by returning false only is the is_external?
method returns true. This makes it subtly inconsistent with
InfoRequest.find_old_unclassified, but it is better I think to
be subtly inconsistent than to risk breaking things that used
to work.
|
| |
| |
| |
| |
| | |
We certainly do not want to send reminder emails for such requests,
for example, since we do not know the email address to send them to.
|
|\ \
| |/
|/|
| |
| |
| |
| | |
Conflicts:
app/controllers/admin_request_controller.rb
config/httpd.conf
spec/models/info_request_spec.rb
|
| |
| |
| |
| | |
cache the associated objects for an info request in the file cache which will be served up without authentication.
|
| |
| |
| |
| | |
doesn't have a PublicBody at the time its slug is being calculated.
|
|/
|
|
| |
CensorRules that aren't attached to a User or Request or Public Body (but don't expose this in the admin UI). Fixes #33
|
| |
|
|\
| |
| |
| |
| |
| |
| |
| | |
Conflicts:
Gemfile.lock
script/handle-mail-replies
script/handle-mail-replies.rb
spec/controllers/request_controller_spec.rb
|
| |\ |
|
| | |
| | |
| | |
| | | |
requested the attention, not the user who made the original request.
|