0

For our production environment, we configured in Rails (version 3.2)

config.action_controller.perform_caching = false

Oddly enough we discovered (by enabling debugging) that SQL queries where hitting the SQL cache when they were coming for a JSON request. Pages never hit the cache and the data was ok.

Does anyone know if there is some special behaviour in Rails for JSON request and SQL caching?

Also, we have config.threadsafe! and we are using JRuby.

N.B. We tested our web pages in Chrome and Safari, both exhibit the same problem: the page itself has the right data, the JSON requests (sometimes) don't.

Note: If someone can shed light whether the QueryCache#call method is used or not in here

https://github.com/rails/rails/blob/3-2-stable/activerecord/lib/active_record/query_cache.rb

it would be great, as it seems that it uses the cache regardless of above setting.

It may be worth mentioning that the particular issue is around a piece of code like current_user.related_object; where the related_object SQL result is being grabbed from the cache. current_user is kept by devise, the authentication gem.

Update

We have tracked the issue, and it seems the SQL cache is not being cleared properly in a multithreaded environment (again, we used JRuby). As all our pages have JSON requests, there were some connections with a not-cleared SQL cache floating around that caused issues in subsequent requests when reused.

As a workaround, we have added a before_filter method in ApplicationController to clear the SQL cache for the current connection.

carlosayam
  • 1,396
  • 1
  • 10
  • 15

1 Answers1

0

it's a middle-ware setup by default, check rake middleware RAILS_ENV=production

you can avoid the query cache, just like any other middle-ware :

config.middleware.delete ActiveRecord::QueryCache

it worth noting that it is not related to config.action_controller.perform_caching ... the query-cache only tries to "cache" per-connection lifecycle (unless there's a tx commit/rollback) the same kind of queries (current_user.related_object called twice) and it's generally a bit counter-productive on JRuby due forcing a DB connection check-out - I recommend disabling.

Community
  • 1
  • 1
kares
  • 7,076
  • 1
  • 28
  • 38
  • Thanks @kares. The odd thing is that `current_user.related_object` does not use the SQL cache (or is empty) for a HTML request, but it uses a previously stored SQL result for a JSON request that passes thru the same code. We were speculating that because the browser has "keep-alive" and may reuse HTTP connections, something could be happening. But that would be odd too - we are lost on this. – carlosayam Feb 05 '15 at 03:56
  • I'm sorry I can not help you with the details since I'm not sure I understand the "real" issue - maybe you should setup a public Rails app demonstrating the problem and ask for help if you're so much into fiddling this out ... – kares Feb 05 '15 at 18:42
  • one of my colleagues is closing the net on something - apparently in multithreaded mode clearing the SQL cache empties the wrong object. I will keep you posted. Thanks a lot!! – carlosayam Feb 05 '15 at 22:17
  • we like the QueryCache middleware, which should be one per request, but as said - it seemed broken for multi-threaded environments (in JRuby). To workaround this issue we added a `before_filter` to clear the SQL cache for the current connection. This is a workaround, not the source of the problem - but the Rails codebase is very complex there ... – carlosayam Feb 09 '15 at 22:57