>Hi Pertti,
>
>There are many interesting scenarios which demand a variety of locking strategies. You have come up with some great ones.
>
>I am on contract with a large company that is rolling-out SAP modules. There are dozens of LOB apps (some 3rd party) written in different languages which have to communicate with a common interface (middleware) to SAP to map legacy GL account transactions to the new SAP GL account structures. The business rules are extremely complex.
>
>Here is a hairball: LOB App(1), LOB App(2), LOB App(i)... are all performing multiple transactions for the same customers which requires an "over limit / budget" business rule validation among others. There are tens of thousands of transactions per day all of which affect the business rule. Two LOB apps process transactions in batch with the others are in real-time. The business layer has to validate the "over limit / budget" business rule (among others) before any transactions are commited to SAP.
>
>You know, the more I think about it, the more we should get paid for implementing solutions to problems like these... :)

Aye! The scenario you describe must be close to neurosurgery in complexity, so, heck yeah we should get paid more! How about THIS business rule: "Optimistic locking requirement for a job automatically increases the final estimate, whatever it is, by 110%" 8-b


p.
>
>
>
>>Jeff,
>>
>>
>>>
>>>The issue becomes less critical depending on the type of transaction which is most common. For instance, an insert could be made to a business object and business rules are validated BEFORE the actual insert transaction is sent to the server. In this case, pessimistic locking is not required. User can edit all day long, go out to lunch, go on vacation... It's the job of the BO. So, maybe we should talk about BO technology - something which has been completely overlooked in this discussion.
>>>
>>
>>
>>Good point. Yet there are STILL situations even with this scenario that may trip the data entry person.
>>
>>1. Say you have a business rule that a parcel's Flood Zone Emergency Designation (FZED) which depends on the address and the number of people living on the parcel.
>>
>>2. You have a parcel database with addresses, occupants and FZED's
>>
>>3. Two people open the same record for editing.
>>
>>4. Person one changes the address from 1 Broadway to 50 Broadway, but doesn't change the number of occupants, which (correctly) leaves the designation unchanged (IOW BO doesn't trigger the change or a warning)
>>
>>5. Person two changes the the number of occupants from 5 to 6, which in HIS/HER (stale) copy of the address (1 Broadway) would not trigger a FZED change, but it WOULD trigger a change on the "fresh" address, 50 Broadway (don't ask...)
>>
>>6. Person two now tries to save the data, and BO fires an error due to the discrepancy between the FZED and address+occupants in the (proposed) target record. Person two looks at his/her screen and determines that his/her designation is correct! Unless the BO can spell out clearly that the error is due to someone else's changes to the record while HE/SHE was editing it, the user is at a loss.
>>
>>
>>The only way to avoid this, IMO, is pessimistic locking. Note that I don't advocate pessimistic locking in ALL situations, I'm just saying that it is a lot cleaner way of handling contention whenever you can get away with it, even with BO's in the optimistic locking scenario.
>>
>>I wonder how, say, travel reservation sites handle this kind of stuff. I guess they don't enforce too many business rules, such as "if a person flies to SFO, he/she can ONLY rent a car at SFO AFTER the plane lands, not BEFORE." Leave it to the customers to be their own BO and know the chronological progression of their travels, I guess.
>>
>>
>>
>>>
>>>>Hi, Pertti,
>>>>
>>>>Thanks for your message. I'm curious to know how many developers out there are using optimistic vs. pessimistic. So far it seems a few more are using pessimistic, though I'm sure there are some on both sides. The main reason I go with pessimistic over optimistic is not because of technology, but because it's the most common approach that was needed.