Wolf
>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)
I think most of the confusion comes from people talking about
container managed OCC where in reality they mean containers
delegating OCC to the DBMS.
>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.
Correct.
>But now it gets interesting.
>Transaction1 tries to write b' to the db.
>For isolation reasons t1 can't yet see
Isolation is key here. It implies serialisation but you don't
get that with OCC. All you get is 'first past the post is the winner'.
The first transaction to complete can commit, others abort.
That's why with Oracle's OCC, you get the following error quite often:
ORA-08177 can't serialise access for this transaction
Cause: Encountered data changed by an operation that occurred after the
start of this serializable transaction.
Action: In read/write transactions, retry the intended operation or
transaction.
With all the associated unknowns for the caller to work out, like:
should I retry?, how long before I should retry?, how many times should
I retry?, will there be potential for livelock if I retry?
>Are there other possibilities for the db
>to handle that problem which avoid the
>deadlock?
>What do you think?
I still believe deadlock detection should be built into the application.
>Wolf
Regards,
Hamid
===========================================================================
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".
