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 [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
