On Fri, Apr 23, 2010 at 16:39, Glenn Little <[email protected]> wrote:
> Is there a fairly clean way though to protect ourselves just via the > code so that if that database goes offline we can perhaps warn ourselves > and then continue running in a deprecated mode? > Sounds like a job for… background jobs! :) Particularly a framework that automatically retries on failures. Delayed Job should fit the bill, and is super easy to get started with. Any data you report synchronously to the end-user should be from some kind of cache, or copied into tables in a database you can rely on. You'll want to figure out points in your application that can fire off jobs asynchronously to warm up those caches. When all is well, the jobs complete quickly, and the data gets stored where it's needed for easy access. When the database is offline, the jobs fail, perhaps reporting their failures, and the application shows stale data or some indication of irregularity. Meanwhile, you can build a controller that reports on the length of the job queue and the number of failed jobs so you can keep an eye out for anything requiring manual intervention. Background jobs are pretty much what you need any time the code you're calling is talking to a service that's not in your direct control, or code that responds, shall we say, less than instantaneously. I'd be curious to hear if you've already considered background jobs, and whether you think that pattern will or won't work for your application. -- Nick Zadrozny -- SD Ruby mailing list [email protected] http://groups.google.com/group/sdruby
