Hi Emmett,
I've think I've seen the problem you've described when using acts_as_ferret
+ ferret DRb server (though I'll assume you aren't actually using ferret --
as the inimitable Engine Yard guys pointed out this weekend during one of
their talks, ferret is a common cause of problems for their users. I
haven't played with ferret in months btw, so this example might be outdated,
but this example illustrates a more general problem, I think). in this
ferret case, the problem, I believe, is that when you have some model Foo
that uses acts_as_ferret and you call foo.save, the COMMIT on the save
transaction occurs *after* the ferret after_create/after_update hooks. So
the COMMIT occurs *after* the call to the ferret DRb server. Normally this
is ok, but if you are indexing large amounts of text (e.g.) or the DRb
server gets busy for whatever reason, we saw that the save transactions can
suddenly take a long time.
The example above illustrates a more general point, I think -- be careful
with what you're doing in your AR hooks. Again, the problem is that when
you save your AR object, that save is wrapped in a transaction, and the
commit on that transaction occurs after the AR hooks like after_create.
To verify this, here's a simple example:
# script/generate model foo && rake db:migrate
class Foo < ActiveRecord::Base
after_create { sleep 10 }
end
# then from script/console
foo = Foo.create
# now watch your database -- the transaction begins, but the COMMIT doesn't
occur until after the 10 seconds of sleep.
So what plugins are you using? And are you using any interesting AR hooks
that could potentially take a long time (like talking to a DRb server or
uploading files to s3 as an after_create, for example)?
Best,
Tikhon Bernstam
Co-founder, Scribd.com
_______________________________________________
Mongrel-users mailing list
Mongrel-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/mongrel-users
