BJ, I don't remember commenting about optimistic locking yet, only about "nesting" of transaction (or lack thereof).
Am I forgetting something? -David On Aug 14, 2010, at 2:36 AM, BJ Freeman wrote: > Matt: > read Davids responses. > in short Optimistic locking as a database Function. > Since ofbiz does it own managing of the data, the database itself does not > have all the info to manage the locking effectively. > > > Matt Warnock sent the following on 8/13/2010 11:45 PM: >> I'm still a bit confused. I think I understand the issues, but not why >> so many people are apparently having trouble with them. Or maybe I >> misunderstand them completely. >> >> Optimistic locking (as I understand it) is used primarily when editing >> an existing record by hand, since record creation and programmed updates >> can just use transactions, which are better for most operations anyway. >> Most common business cases I can imagine would not usually involve 2 >> people editing (not just viewing) the same record at the same time. >> What business scenario causes these apparently common collisions? >> >> Most high-volume business uses don't edit other people's records. If I >> enter an e-commerce order for example, I create the header record, >> several line item records, perhaps some other stuff. Eventually I >> commit the whole order at once, when it is assigned an order number and >> becomes part of the main database, which can all be done in a single >> transaction. >> >> Others may be entering similar orders, but they are creating different >> header records with different associated line items. These records >> should all be accumulated into memory-only or temporary tables (I would >> assume) until they are committed to the database, and optimistic locking >> should never really enter into it, as these records are private to the >> user and current session (like an e-commerce shopping cart) until they >> are committed. If they are abandoned before they commit, they should >> never leave a trace in the main database, as I see it. Any code that >> updates the record (to total it, apply taxes, figure shipping, or >> whatever) can work in-memory, or in a single transaction on the >> temporary records, until the whole thing is committed. >> >> If I then go back and edit an order, it is usually one I just recently >> entered, and in most cases, no one else should be using it. When I do >> that, the optimistic lock code should read the record data and note the >> time that the record was last modified (or the data itself). I then edit >> that data on-screen, and when I commit, it first checks to see that the >> data was not modified in the meantime. In most cases, it wasn't >> modified, and the new data is written, again within the scope of a >> single transaction. >> >> If the last-modified date (or the original data) has changed, then a >> collision has occurred, and the system should cancel my commit, because >> I was editing data which has changed while I was editing it, and is now >> stale. In most cases, any manual edit takes much more than a second, so >> the chance of a time granularity collision on an actual record edit >> seems miniscule. If there is a collision, the system re-reads the >> recently updated data, tells me about the collision, probably discards >> the previous edits, and I can then edit again if necessary. >> >> It's a poor substitute for an update transaction, but you don't want to >> lock a database up for several minutes while a user edits a record by >> hand, and most transactions will timeout long before the user finishes >> the edit. >> >> Programmatic data updates like Mike Z describes are much more common, >> but they can usually be managed in a single transaction too. I don't >> need a lock to calculate a total, enter a timestamp, or similar updates, >> as these can all be done inside an ACID transaction, thereby protected >> from other threads, users, application servers, or whatever. We can >> even suspend one transaction to run an unrelated one, then resume the >> first, as David suggested earlier in this thread. >> >> Can you give me an example of the kind of update that leads to the kind >> of concurrency issues you describe? Is OFBiz using optimistic locks >> where transactions are really required? Or what about James' inventory >> count scenario prevents using a transaction instead of an optimistic >> lock? What am I missing? Just want to know where the big bear traps >> might be. Thanks in advance. >>
