> 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
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
>From my understanding serializable can have a noticeable effect on
performance because of large transactions which can be partially processed
before being aborted (vs. row locking at the start of the transaction) - of
course for one specific case I think both would be fine - but more
generally
Here is one example from production - an order has a fulfillment - the
fulfillment can be deleted if it is not 'shipped', very roughly:
# update
transaction do
fulfillment.status = 'shipped'
fulfillment.save!
StockMovement.new(fulfillment).save
end
# delete
transaction do
fulfillment.
Judging from how few resources I have found detailing pessimistic locking
usage in Rails - one is inclined to say that optimistic locking is by far
the most common approach. Unfortunately optimistic locking simply does not
provide any real guarantees once you have scaled past a single dyno (if i
Hello Richard,
Thanks for the response. Unfortunately I'm not sure how it's possible to do
this without the Hash look-up. For example one might imagine adding
something like this to ActiveSupport::Callbacks (which would prevent more
than one string from being permanently allocated):
@@_curr
Hello,
I've been trying to track-down a pretty significant memory bloat issue with
ActiveRecord objects. Running some generic experiments e.g. an empty model
with 6 enum_fields, created_at, updated_at - and fetching 72000 of these
with ActiveRecord from a Postgres Database allocates approximate
