Am Samstag, 9. Januar 2016 06:33:50 UTC+1 schrieb alexande...@gmail.com:
>
> > 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 eve
> 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
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
You problem hast nothing todo with multiple dynos. This race condition can
occour as soon as you have multiple workers or threats (whatever your
server uses). But
its a normal issue and in my point of view you can handle it with
optimistic locking just fine.
When you use optimistic locking rail
