Jens,
your statement about deadlocks is not quite correct. A deadlock means that 2
clients have successfully acquired exclusive locks on certain resources, and
now, in order to proceed, need to access a second resource, which is the
exact one that the other client already holds (the well-known "dining
philosophers problem" often referred to). Example:
A locks R1
B locks R2
A now needs R2 and waits, therefore does not release R1
B now needs R1 and waits, does not release R2
result: A and B are stuck. Somebody else (a deadlock detection algorithm)
needs to step in and choose the participant to throw out.
Locking in itself does not necessarily imply the above. It is the circular
dependency that makes up a deadlock. (BTW, a deadlock is not a type of lock,
but rather a situation that can occur when locking is used).
In a normal locking situation, one participant will simply wait for the lock
to be released - and depending on a timeout value, a lock timeout exception
may occur.
my 2 cts.
=====================================
But "repeatable read" does only guarantee, that during a transaction of a
client a read on the same entity will lead to the same result unless this
client itself changes the entity, regardless off parallel working other
clients which could change this entity. But another client will not be
halted if it wants to read this entity. If then both clients want to modify
the same entity after they have read it both (and therefore it cannot be
changed directly due to the "repeatable read"), we get a wunderful deadlock.
Let us take an entity X and the clients A and B, in paranthesis my
assumptions of what happens in the server.
A reads X <- allowed (make a copy?)
B reads X <- allowed (make a copy?)
A writes X <- allowed (change A's copy?)? Or already
forbidden (if there are no copys)?
B writes X <- forbidden in any case, result would be
undeterministic
