Alex MacCaw
2009-Mar-07 14:34 UTC
Any reason why after_save & after_create are wrapped in the transaction?
I''ve got a message queue running, and record ids get added to it in an after_create callback. However, the message queue is so fast that it can''t find the records. This is because the record hasn''t actually been saved back to the database yet - after_create is called in the transaction. There''s more information on this problem here: http://elimiller.blogspot.com/2007/06/proper-cache-expiry-with-aftercommit.html I''m wondering, is there a reason why after_save and after_create are called inside the transaction? --~--~---------~--~----~------------~-------~--~----~ 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@googlegroups.com To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
Eloy Duran
2009-Mar-07 16:40 UTC
Re: Any reason why after_save & after_create are wrapped in the transaction?
They are inside the transaction because of the reason mentioned in the article you linked to: > I noticed a troubling thing about using after_save to expire caches, after_save is still within the transaction that save is automatically wrapped in. I assume this is to protect against an error during the after_save call, so you can roll back the database to it''s previous state. So maybe a patch to add the after_commit API, as used in the article, would be a good idea. Eloy On 7 mrt 2009, at 15:34, Alex MacCaw wrote:> > I''ve got a message queue running, and record ids get added to it in an > after_create callback. > > However, the message queue is so fast that it can''t find the records. > This is because the record hasn''t actually been saved back to the > database yet - after_create is called in the transaction. > > There''s more information on this problem here: > http://elimiller.blogspot.com/2007/06/proper-cache-expiry-with-aftercommit.html > > I''m wondering, is there a reason why after_save and after_create are > called inside the transaction? > >--~--~---------~--~----~------------~-------~--~----~ 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@googlegroups.com To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
Pratik
2009-Mar-07 16:43 UTC
Re: Any reason why after_save & after_create are wrapped in the transaction?
On Sat, Mar 7, 2009 at 4:40 PM, Eloy Duran <eloy.de.enige@gmail.com> wrote:> So maybe a patch to add the after_commit API, as used in the article, > would be a good idea.Or if possible, just use observers. -- Cheers! - Pratik http://m.onkey.org --~--~---------~--~----~------------~-------~--~----~ 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@googlegroups.com To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
Alex MacCaw
2009-Mar-07 17:31 UTC
Re: Any reason why after_save & after_create are wrapped in the transaction?
Ah, sorry, I should have read it closer. I didn''t realize that errors in after_save/after_create would roll back the save. On Mar 7, 4:40 pm, Eloy Duran <eloy.de.en...@gmail.com> wrote:> They are inside the transaction because of the reason mentioned in the > article you linked to: > > > I noticed a troubling thing about using after_save to expire > caches, after_save is still within the transaction that save is > automatically wrapped in. I assume this is to protect against an error > during the after_save call, so you can roll back the database to it''s > previous state. > > So maybe a patch to add the after_commit API, as used in the article, > would be a good idea. > > Eloy > > On 7 mrt 2009, at 15:34, Alex MacCaw wrote: > > > > > I''ve got a message queue running, and record ids get added to it in an > > after_create callback. > > > However, the message queue is so fast that it can''t find the records. > > This is because the record hasn''t actually been saved back to the > > database yet - after_create is called in the transaction. > > > There''s more information on this problem here: > >http://elimiller.blogspot.com/2007/06/proper-cache-expiry-with-afterc... > > > I''m wondering, is there a reason why after_save and after_create are > > called inside the transaction?--~--~---------~--~----~------------~-------~--~----~ 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@googlegroups.com To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
Alex MacCaw
2009-Mar-07 17:31 UTC
Re: Any reason why after_save & after_create are wrapped in the transaction?
Thanks for the suggestion, will do. On Mar 7, 4:43 pm, Pratik <pratikn...@gmail.com> wrote:> On Sat, Mar 7, 2009 at 4:40 PM, Eloy Duran <eloy.de.en...@gmail.com> wrote: > > So maybe a patch to add the after_commit API, as used in the article, > > would be a good idea. > > Or if possible, just use observers. > -- > Cheers! > - Pratikhttp://m.onkey.org--~--~---------~--~----~------------~-------~--~----~ 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@googlegroups.com To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
Jan De Poorter
2009-Mar-09 14:39 UTC
Re: Any reason why after_save & after_create are wrapped in the transaction?
As far as I can see observers after_save calls are still in the transaction. regards, Jan De Poorter http://workswithruby.com On 07 Mar 2009, at 18:31, Alex MacCaw wrote:> > Thanks for the suggestion, will do. > > On Mar 7, 4:43 pm, Pratik <pratikn...@gmail.com> wrote: >> On Sat, Mar 7, 2009 at 4:40 PM, Eloy Duran >> <eloy.de.en...@gmail.com> wrote: >>> So maybe a patch to add the after_commit API, as used in the >>> article, >>> would be a good idea. >> >> Or if possible, just use observers. >> -- >> Cheers! >> - Pratikhttp://m.onkey.org > >--~--~---------~--~----~------------~-------~--~----~ 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@googlegroups.com To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
Alex MacCaw
2009-Mar-09 14:43 UTC
Re: Any reason why after_save & after_create are wrapped in the transaction?
Yes, I''m still getting the error. On Mar 9, 2:39 pm, Jan De Poorter <j...@openminds.be> wrote:> As far as I can see observers after_save calls are still in the > transaction. > > regards, > Jan De Poorterhttp://workswithruby.com > > On 07 Mar 2009, at 18:31, Alex MacCaw wrote: > > > > > Thanks for the suggestion, will do. > > > On Mar 7, 4:43 pm, Pratik <pratikn...@gmail.com> wrote: > >> On Sat, Mar 7, 2009 at 4:40 PM, Eloy Duran > >> <eloy.de.en...@gmail.com> wrote: > >>> So maybe a patch to add the after_commit API, as used in the > >>> article, > >>> would be a good idea. > > >> Or if possible, just use observers. > >> -- > >> Cheers! > >> - Pratikhttp://m.onkey.org--~--~---------~--~----~------------~-------~--~----~ 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@googlegroups.com To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
Alex MacCaw
2009-Mar-10 14:18 UTC
Re: Any reason why after_save & after_create are wrapped in the transaction?
Here''s a little lib I wrote that implements support for after_commit callbacks: http://gist.github.com/76868 On Mon, Mar 9, 2009 at 2:43 PM, Alex MacCaw <maccman@gmail.com> wrote:> > Yes, I''m still getting the error. > > On Mar 9, 2:39 pm, Jan De Poorter <j...@openminds.be> wrote: > > As far as I can see observers after_save calls are still in the > > transaction. > > > > regards, > > Jan De Poorterhttp://workswithruby.com > > > > On 07 Mar 2009, at 18:31, Alex MacCaw wrote: > > > > > > > > > Thanks for the suggestion, will do. > > > > > On Mar 7, 4:43 pm, Pratik <pratikn...@gmail.com> wrote: > > >> On Sat, Mar 7, 2009 at 4:40 PM, Eloy Duran > > >> <eloy.de.en...@gmail.com> wrote: > > >>> So maybe a patch to add the after_commit API, as used in the > > >>> article, > > >>> would be a good idea. > > > > >> Or if possible, just use observers. > > >> -- > > >> Cheers! > > >> - Pratikhttp://m.onkey.org > > >-- http://www.eribium.org | http://socialmod.com --~--~---------~--~----~------------~-------~--~----~ 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@googlegroups.com To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---