David Wall wrote: > > Rickard's description of optimistic and pessimistic locking is correct in > the > > computer science sense. I won't get into what happens with real products. > These > > are two different approaches to handling resource contention. > > That is absurd, since there is no such thing as a "correct" description in a > computer science sense. Computer science deals with many variations on a > theme. OK, so you don't like my wording. How about "Rickard's description follows the common definition of optimistic concurrency control used by computer scientists." Yes, computer science deals with many variations as I also stated, but my first statement still stands. > For one thing, in the pedantic view, you can't have "optimistic > locking" since that implies locks, which is what is avoided by the "computer > science" definition of optimistic concurrency control which is timestamp > based. OK, lets agree to call it optimistic concurrency control. Optimistic locking was just a shorter term, but somewhat misleading as you point out. There are many means of achieving optimistic concurrency control of which timestamps are one crude method. I won't get into a discussion of the details here since I assume most know the literature. In case you don't one of the seminal papers on the topic is Kung, H. and J. Robinson (1981), "On Optimistic Methods for Concurrency Control." ACM Transactions on Database Systems, 6(2): 213-226. Copyright 1981, ACM Inc. And while I'm giving references the fundamentals of concurrency in databases is handled well in C.J. Date, An Introduction to Database Systems, Volume II: Chapter 3. Copyright 1983, Addison-Wesley Publishing, Company, Inc. > Also, real products is where it's at unless you are doing a theory > course. "Computer science" optimistic is even more impossible in a > distributed db environment. I use theory to implement real systems all the time. You should try it. It removes a lot of guess work and questions like how to avoid deadlocks :-) > > > Of course, there may be some commercial dbs out there that implement the > most pure of optimistic concurrency control, but I'm not familiar with any. > Nearly every database I've seen uses locks, and locks are locks are locks. > Locks can cause deadlock situations, and it's up to the resource managers > and the like to possibly detect this and recover, or to ensure that programs > lock resources in the same order. I suspect few db systems really have > deadlock detection that works in all cases as it generally degrades the > database performance for every transaction to save a few poorly architected > systems. If you don't employ locking, then you may create "starvation" in > which an optimistic transaction never can complete because it takes too long > and other transactions continually interrupt the longer running one. > > What db are you using that has the optimistic locking that was described? For all intents and purposes, the persistence layer and databases I use achieve optimistic concurrency control without fear of deadlocks. This is achieved through careful design of the persistence layer and sticking to doing all updates with entity beans. A given object or object graph is only updated by a single entity bean and that bean always performs the updates in the same order. I use a relational DBMS which locks rows on writes (for instance Oracle). All writes happen at the end of the transaction during the ejbStore phase. The duration of all locks is on the order of a few milliseconds. In addition, the persistence layer checks for update conflicts in the write operation so both are in the same atomic operation. Given all these facts, I don't stay up late at night worrying about deadlocks. Starvation is a possibility, but one which I don't worry about either. I haven't had a system yet where objects with a high degree of concurrent updates are required in long transactions. Again it's by design. --Victor Langelo =========================================================================== 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".
