mrblack.co.uk weblog

I’m currently making an app that will spit out pdf reports all over the shop. These reports will get kinda big, doing loads of database calls and rendering images. As such it could take 15 seconds or more to render. Making the reports on the fly therefore could be a horrid user experience with unexpected waits and halts (and a nightmare for a server admin).

So my first attempt was batch the process, as the majority of the data that the pdfs render only changes about once a day. The batch process would go through our database and render all the reports and dump them out to file. User access then would be instantaneous. Wonderful!

The problem is that some bits of data can change at any time. For example these reports display a contact name and email address at the top. So if that changed, the pdf wouldn’t reflect this. Not very professional.

To combat this I added a spooling table, where if some data changed a request was added to a table. A script would then run every minute that would process the pending requests.

This is a slightly dumb approach, I know. What I need is two threads. So when the user updates the contact information, one thread would render the html page as usual and the other to render the pdf. The benefit being that the user doesn’t have to wait for the pdf thread to complete.

Ruby can deal with threads but finding information about doing a task like this is tough, let alone with Rails. Any help out there?

Readings
Rails wiki on threads
Ruby Reliable Messaging Gem
Reliable Messaging Rails example

This entry was posted on Thursday, March 22nd, 2007 at 10:44 pm and is filed under Apps, Code, General, ruby, rubyonrails. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.