Nick's idea is another good solution. A sinatra app could do caching for you also but it just depends on how you need to access the data.
Martin Emde Tw: @martinemde On Sat, Apr 24, 2010 at 12:46 AM, Nick Zadrozny <[email protected]>wrote: > 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 > -- SD Ruby mailing list [email protected] http://groups.google.com/group/sdruby
