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.
