> Pessimistic locking, the way you want to use it, decreases performance
because all reads have
to wait until the lock is gone. For the web this is realy a bad thing.
Futhor more the chance of a deadlock
is every time ahead of you.
Reads should not be locked by a FOR UPDATE lock
(http://www.pos
Taking Celluloid out is easier than taking faye/eventmachine.
One approach could be to do as in activejob, i.e. leave the interface and a
dev-only implementation in Rails and let other gems to the heavy work.
This would greatly improve the choices, as eventmachine is not the only
event-based W
A cool feature in the rails engines could be to define callbacks for the
case in which a rails app will be forked into a new process.
Why this could be important?
For years, unicorn has warned us to always disconnect and reconnect to the
database in its own custom callbacks. Passenger has such
In this case I would still use optimistic locking. You can simply call
.touch on the associated object (in both transaction), so the lock_version
is increased.
Pessimistic locking, the way you want to use it, decreases performance
because all reads have
to wait until the lock is gone. For the we
Sorry, yes you are correct that was a poor example and for that particular
condition optimistic locking will validate correctly. On the other-hand
conditions which use data from a reference but do not update that reference
will still be able to race .e.g.
A fulfillment has fulfillment_line_ite
