Wolf Siberski wrote:
> Hey, that's a surprise. Before I read Your post I
> was convinced that optimistic locking is deadlock free.
> But While trying to write an answer to convince You, too,
> I got serious doubts, and now I'm not sure at all about it.
>
> Let's simulate a simple concurrent update to get
> that more clear. Suppose we have Bean a (for simplicity
> stored in table A ) and Bean b (stored in B)
>
> The core idea of optimistic locking is
> working copies. Transaction1 gets
> it's working copies of a and b just by reading
> without any locking. The same for transaction2.
>
Perhaps the thing that you are missing out in your thinking (or at least in this
write-up) is that optimistic concurrency is not just implemented by the client.
The server is fully involved, and there is server-side state to ensure that such
a scheme is implemented.
>
> Now t1 and t2 start to update their copies
> which leads to a' and b' rsp. a'' rsp b''.
>
> Both transactions start to write their changes back.
> t1 writes a' to the db. No (explicit) locking involved.
> t2 writes b'' to the db. No (explicit) locking involved.
>
> But now it gets interesting.
>
> Transaction1 tries to write b' to the db.
> For isolation reasons t1 can't yet see
> the change from a to a'.
> Will the update succeed? I don't think so.
The update will succeed. t1's commit will fail, if t2 commits.
If t2 rolls back, t1 has no problems.
> My guess is that the db will wait until
> transaction2 is completed.
Nope. There is no waiting in optimistic concurrency schemes, which is why there
are no deadlocks.
-Sriram
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
