I'll provide an example so that people don't say that the difference is theoretical :)))) Take an Order. The user submits an Order on some site. The Order is channled say to the Wharehouse (does not necessarly change systems or databases, it can be in the same
application and/or database). In the Warehouse someone picks the Order (Say the Picker), checks the availability of the products in the Warehouse and notifies the Finantial that a product will be delivered and it needs a receipt. So the Order goes on being
used on several business activities. You may think that concurrency is all over the place, well may be not :) Basically the Order goes on different states (stages/activities). First it is Submitted, then is Reviewed by the Picker (may be he will split create
two Shipping Receipts) so state "in Revision" (so no one will take of the order while the Picker is reviewing it, the reason why is not becouse of concurrency but practical work considerations), etc. If several Pickers where allowed it would mean that Picking
is not done in terms of the Order but its Order Lines (a Picker would select an Order Line to be picked). If eventually the Picker stops picking the Items in the Order (say went home), the company policy may mandate that automatically its scheduled to the
next Picker available, etc etc. So in the end you have concurrency, but a controlled concurrency (so little low level chances of write-write conflicts that need to be trapped). Concurrency in terms of data is related to data integrety and resource contention,
but when it comes to business level is about knowing who is doing what, when and why and with what efficiency within the scope of an established business process schema. Nuno
I appreciate your time putting up an example, however I fail to see why concurrency (optimistic or pessimistic) is at stake here. I think your example is perfect in illustrating that scheduling the work in a proper way will result in NO concurrency conflicts.
:) Also: what will be the result if a picker for some reason due to a used optimistic/pessimistic scheme has a conflict and the order fails. How is that reported to the customer? And why is that the problem of the customer? I understand what you're saying,
but it's fighting sympthoms instead of solving the real problem. I also learned the different schemes and how they can help you and all, but if you're think of it, it's pretty weird that they are used deep down a chain of activity with results which can be
avoided. So I'd like to see that more developers would look into solving this problem (which is a big problem, let's not forget that) on a higher, more abstract level, so lowlevel problems related to concurrency are avoided AND the software is more efficient.
Lead developer of LLBLGen Pro, the productive O/R mapper for .NET
LLBLGen Pro website: http://www.llblgen.com My .NET blog: http://weblogs.asp.net/fbouma
Microsoft MVP (C#)
Hi Frans, "Data-integrity protection using optimistic or pessimistic locking is a farce. Here's why: two processes do the same work. Based on the concurrency scheme process A or process B is doing work which will be abandoned. However, who says that that work
isn't required? If B mutates a user row, and A has done that already, making B's changes void, who says A's data is correct and B's isn't? (Semantically speaking). After all, data-integrity is about semantic values given to data inside a database: all mutations
on multiple tables are done in transactions anyway which protect data-integrity." That is why you can use "SELECT FOR UPDATE" in case of pessimistic locking, and versioning in case of Optimic Locking. In the former A issues a SELECT FOR UPDATE, so basically
process B when issues a SELECT FOR UPDATE is waits until A finishes the transaction and then proceeds. In the later, who ever writes the first time wins, but with versioning process B will probably abort the action upon updatin the same object (version do
not match). So in the former updates are in fact serialzed, in the later the application is given the ooportunity to ask the user what he wants to do (merge, update anyway, abandon action). "You can't save your work because of concurrency schemes" No. "The
Order is being picked by user X" or "The Order is being picked by user X, do you want to proceed or recall picking" :) "1) you have just voided the work of user ABC or 2) Your work can't be stored because of user ABC who has made some changes already." If
one made changes already as a reason within a business process. As you said most applications are not built to store and retrieve, but to automate and facilitate work. So the application should map and use the language of the user within the scope of the problem
domain. Technically the data was already update, but semantically data was already updated within the scope of a business context. What lacks most developers is the ability to see their work beyond technology and understand why sometimes two user may want
to update the same data concurrently or not. If we forget application use cases and focus on agents performing work, agent B should be prepared to abort to decide what to do in this case (proceed, abort, or delay). Whatever action agent B chooses it is serialized.
"which is the worst possible spot you can think of to stop a process/user to do work." If anything/anyone stops working becouse of write-write conflicts means that the solution was not well designed. It does not means tha optimistic locking or pessimistic
did not performed they work well. It means that agent B (in case of optimistic locking) did not knew what do do in this case (proceed, abort,, or retry all over again) and he should know otherwise pessimistic locking should have been used (by default everything
is serialized :). The problem of "everything is serialized by degaulf" is precisely one of resource contention (WAIT UNTIL I FINISH even if it takes ....). That is why Optimistic locking is usefull (minimized resource contection) but in the other side Agent
B is left to decide by "himself" what to do next. What happens with Optimistic Locking is that Agent B is usually a Human when we speak of busines applications :). Segregating the problems is usefull to better understand what is at stake. "Solve that, not
the results the problems give" There is no problem ... if you know how to use both strategies and for what they were defined. I have still to find an application that automatically decides by its "own" if an Order should be Picked by one or several Pickers
just becouse, hey a Picker can overwrite the values another Picker. In other words I still have to find an application that understand the semantics of any another application and automaticaly adapts to its need (a business process). Basically what it means
that the so called application forces one to use a "work" policy that might fit or not a particular situation, if not hammer it or build you own mechanism to fit the goal. "Declaring the problems as two different things is the wrong way to go" I think it is
at allows one to explore things such as Workflows to organize work and activities and not to be dead locked on Pessimistic Locking :) Nuno
Hi Frans, sorry for my last remark, it was just a game of words and I noticed that could be taken bad. "however I fail to see why concurrency (optimistic or pessimistic) is at stake here" Exactly it is not. So to say that "Pessimistic Locking" or "Optimistic
Locking" prevents one to work (work is forced to be scheduled) it is IMHO an exageration. "I understand what you're saying, but it's fighting sympthoms instead of solving the real problem." Where is the problem? The problem might be if you are looking for
an Universal Solution to deal with resource contention and usage in a highly concurrent environment. I must say that my degree is in Computer Science, so I had to learn some of this stuff in mathematical therms (forget IT for a moment). The problem of dead
locking is of acyclic graphs, when you have acyclic graphs and you need to decide what to do once one understands that is going on and on in circles the most elegant solution was actually provide by Turing in 46 I think. Simply use an Oracle (The Matrix Returns).
"So I'd like to see that more developers would look into solving this problem (which is a big problem, let's not forget that)" As far as I understand your problem, they have. Not developers but scientists from physics and maths to psychology and biology. Nuno
Lopes
Most computer programs when they need to do something they prefer to wait, as they don't know what to do meanwhile as quite often they don't have a choice. Serialize or die/abort. Nuno
::which built-in next version of SQL Server (Yukon)? It IS NOT BUILD INTO YUKON. ObjectSpaces is part of the .NET framework 2.0, which yukon also requires and which will ship at the same timeframe. it is not part of YUKON, it is part of the .NET framework.
Hi, I've wrote: "That is why you can use "SELECT FOR UPDATE" in case of pessimistic locking, and versioning in case of Optimic Locking. In the former A issues a SELECT FOR UPDATE, so basically process B when issues a SELECT FOR UPDATE is waits until A finishes
the transaction and then proceeds. " And I mentioned in the end "dead locks". Probably people don't understand the connection as I've heard of no replies. Basically through the use of SELECT FOR UPDATES and Pessimistic Locking one has a way to assure that
data conflicts as "automatically" tackled and serialization is a solved issue. The main problem is that if * Agent A issues a SELECT FOR UPDATE on a set of Data sA * Agent B issues a SELECT FOR UPDATE on a set of data sB * Agent A issues a SELECT FOR UPDATE
on a set of data sB (A waits) * Agent B issues a SELECT FOR UPDATE on a set of data sA (B waits) * --------------- DEAD LOCK This actions cannot be serialized withou an Oracle if sB and sA is imporatnt data for B to do his work, and sA and sB is imporant data
for A to do his work. Say both A and B calculate different "totals" to be stored on some other record. Cheking/Checkout is just tha same as explicit locking done with "SELECT FOR UPDATE" Nuno
It doesn't make sence, ObjectSpaces will be a FREE O/R mapping for .NET/SQL Server ;) Thona, what do you think about it, as a owner of a same tool (EntityBroker, right?)? :) Tien,
nbplopes
Participant
1745 Points
349 Posts
Re: O/R Mapping Tools for .NET
Dec 04, 2003 04:13 PM|LINK
FransBouma
Participant
1509 Points
312 Posts
Re: O/R Mapping Tools for .NET
Dec 04, 2003 04:25 PM|LINK
LLBLGen Pro website: http://www.llblgen.com
My .NET blog: http://weblogs.asp.net/fbouma
Microsoft MVP (C#)
nbplopes
Participant
1745 Points
349 Posts
Re: O/R Mapping Tools for .NET
Dec 04, 2003 04:52 PM|LINK
nbplopes
Participant
1745 Points
349 Posts
Re: O/R Mapping Tools for .NET
Dec 04, 2003 05:07 PM|LINK
nbplopes
Participant
1745 Points
349 Posts
Re: O/R Mapping Tools for .NET
Dec 04, 2003 05:19 PM|LINK
Tiendq
Member
441 Points
96 Posts
Re: O/R Mapping Tools for .NET
Dec 05, 2003 01:50 AM|LINK
thona
Member
20 Points
2923 Posts
Re: O/R Mapping Tools for .NET
Dec 05, 2003 09:03 AM|LINK
PontiMax
Member
415 Points
83 Posts
Re: O/R Mapping Tools for .NET
Dec 05, 2003 09:43 AM|LINK
nbplopes
Participant
1745 Points
349 Posts
Re: O/R Mapping Tools for .NET
Dec 05, 2003 06:24 PM|LINK
Tiendq
Member
441 Points
96 Posts
Re: O/R Mapping Tools for .NET
Dec 06, 2003 12:53 AM|LINK