Hamid Lahooti wrote:
>
> Do you agree that when two or more concurrent transactions
> update two or more
> resources without following a strict order, there's potential
> for deadlock?
>
> If you do, then can you elaborate how optimistic concurrency
> can be deaklock
> proof unless the container/resource manager has prior knowledge of the
> application's execution plan.
>
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.
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.
My guess is that the db will wait until
transaction2 is completed.
But now t2 starts to write b''...
Looks like a deadlock to me.
(had we used a lower isolation level here,
t1 would have got a db error when writing a';
but the interesting case is complete transaction
isolation).
Are there other possibilities for the db
to handle that problem which avoid the
deadlock?
What do you think?
Wolf
----------
wolf siberski at tui nospam de
--== Sent via Deja.com http://www.deja.com/ ==--
Before you buy.
===========================================================================
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".
