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.