On Mon, 31 Jul 2000 15:53:27 +0100, Lahooti, Hamid
<[EMAIL PROTECTED]> 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?
Yes, the potential being that pessimistic concurrency control is used.
With optimistic locking this is impossible since concurrent transactions
get "their own version", and hence never compete for the exact same
resource.
>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.
Victor is really really right. You really should read up on optimistic
concurrency control and how it works. Again, there can be no deadlock
with optimistic concurrency control, because that assumes that two
concurrent transactions want the *same* resource/data, and with
optimistic concurrency control two concurrent transactions accessing a
particular piece of data will get different versions of this data, hence
avoiding deadlock. By using some form of timestamp mechanism possible
commit conflicts (both tx's have tried to modify the same data) are
resolved by letting the tx that tried to commit last rollback.
This discussion will not proceed productively until you understand what
we are talking about here. I recommend that you read the book
"Fundamentals of Database Systems"
(http://www.amazon.com/exec/obidos/ASIN/0805317554/o/qid=965057913/sr=8-1/ref=aps_sr_b_1_3/102-3310637-4922569)
for further info on this particular topic.
best regards,
Rickard
--
Rickard �berg
Email: [EMAIL PROTECTED]
http://www.telkel.com
http://www.jboss.org
http://www.dreambean.com
===========================================================================
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".
