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:

I'm wondering, is there a reason why after_save and after_create are
called inside 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.


Or if possible, just use observers.

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

Thanks for the suggestion, will do.

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

Jan De Poorter

Yes, I'm still getting the error.

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