Concurrency options: Optimistic/Pessimistic/Last-Win
-
Hi. A philosophical question cooncerning concurrency: Optimistic/Pessimistic/Last-Win I understand the difference among the three options. It's well explained in MSDN: Reference: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vbcon/html/vbtskperformingoptimisticconcurrencychecking.asp But I can't quite relate the three options to real life situations - so, examples welcomed. Anyway, for my experience, "Last-Win", and "Pessimistic", concurrency is sufficient for most circumstances I encountered. When do we need optimistic concurrency? Thanks! norm
-
Hi. A philosophical question cooncerning concurrency: Optimistic/Pessimistic/Last-Win I understand the difference among the three options. It's well explained in MSDN: Reference: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vbcon/html/vbtskperformingoptimisticconcurrencychecking.asp But I can't quite relate the three options to real life situations - so, examples welcomed. Anyway, for my experience, "Last-Win", and "Pessimistic", concurrency is sufficient for most circumstances I encountered. When do we need optimistic concurrency? Thanks! norm
If I understand the three correctly: Pessimistic concurrency control - a row is unavailable to users from the time the record is fetched until it is updated in the database. Doesn't this mean that there's an assumption that the record is being fetched so that it can be updated? That would imply that during the time the client is hanging on to the record, nothing else can get done? Or is this referring only to the "fetch-change-put" time of the server, say, when an UPDATE command is executed? And isn't this method not really very usable in situations where the records are fetched and the connection closed? These assumptions would seem to be correct based on what the site says. It's funny they use inventory as an example. I've written an inventory management system that uses optimistic concurrency. The connection is always open, and the only time there's violation is when someone is updating a record that is simultaneously being accessed. This hardly ever happens. 90% or more of the transactions are fetches--part look up, reporting, price lookup, qty look up, etc. Only when a part is received or sold is there a write transaction. It would be impossible for me to run this system in a pessimistic mode, because records are always being fetched on a continuously open connection. And they're being fetched simply for read, not update, purposes. Does that help, or am I misunderstanding something? Marc Latest AAL Article My blog Join my forum!
-
Hi. A philosophical question cooncerning concurrency: Optimistic/Pessimistic/Last-Win I understand the difference among the three options. It's well explained in MSDN: Reference: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vbcon/html/vbtskperformingoptimisticconcurrencychecking.asp But I can't quite relate the three options to real life situations - so, examples welcomed. Anyway, for my experience, "Last-Win", and "Pessimistic", concurrency is sufficient for most circumstances I encountered. When do we need optimistic concurrency? Thanks! norm
How about an airlines telling you that you can get a seat NOW, but then when you actually try it a second later they say someone's already taken it?
-
How about an airlines telling you that you can get a seat NOW, but then when you actually try it a second later they say someone's already taken it?
Thanks for the response first of all. Makes sense and I think the concept is beginning to sink in and take hold a little more. Now, responding to saikatsen: "How about an airlines telling you that you can get a seat NOW, but then when you actually try it a second later they say someone's already taken it? " In that case: 1. Check for seat: "Last Win" 2. Book a seat: "pessimistic concurrency" norm