Any reason why after_save & after_create are wrapped in the transaction?

rubyonrails-core
1

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?

2

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

3

Or if possible, just use observers.

4

Ah, sorry, I should have read it closer. I didn't realize that errors in after_save/after_create would roll back the save.

5

Thanks for the suggestion, will do.

6

As far as I can see observers after_save calls are still in the
transaction.

regards, Jan De Poorter http://workswithruby.com

7

Yes, I'm still getting the error.

8

Here’s a little lib I wrote that implements support for after_commit callbacks:

http://gist.github.com/76868