logo      
Custom Search

Re: Support for processing after the response has been transmitted?

Date: December 31, 2006
From: Courtenay <court3nay@xxxxxxxxx>

In-reply-to: <5CDE7C3D-F1E5-443E-B6ED-9578620D6F5B@xxxxxxxxxxxxxxxxxx>
References: <1167496474.441721.69240@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <9258D900-2931-4BFF-A14E-CEFAB1D1B8EF@xxxxxxxxxxxxxx> <5CDE7C3D-F1E5-443E-B6ED-9578620D6F5B@xxxxxxxxxxxxxxxxxx>


On 12/30/06, Josh Susser <josh@xxxxxxxxxxxxxxxxxx> wrote:
>> Is there any interest in allowing controller methods to do
>> post-response processing?
>
> I'm pretty sure you can just do the following:
>
> def show
>   # fetch me something to render
>   render
>   # do some long operation
> end

Yes, you can do that, but it won't render until the method returns.

A pretty simple way to accomplish this is to use BackgrounDRb to do
the work in another process.

What you mean to say is, no, you shouldn't do it that way :) since
it'll tie up the controller.

You could fork off a process and detach it if you're not interested in
the results.  Take a look at the daemonize library.

Also check out this gratuitous self-link at
http://blog.caboo.se/articles/2006/10/14/premcache-caching-and-precaching-with-memcached
if that's the sort of thing that floats your boat.

Courtenay
http://blog.caboo.se

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Ruby on 
Rails: Core" group.
To post to this group, send email to rubyonrails-core@xxxxxxxxxxxxxxxx
To unsubscribe from this group, send email to 
rubyonrails-core-unsubscribe@xxxxxxxxxxxxxxxx
For more options, visit this group at 
http://groups.google.com/group/rubyonrails-core?hl=en
-~----------~----~----~----~------~----~------~--~---





Custom Search
home | non blog view