Optimistic locking is when you lock a record at the last possible moment. In "old style" Progress (before we got events, methods and attributes in version 7) a lot of programs locked a record when it was displayed on the screen so the moment a user could start to update the information. This means that a record can potentially be locked for a long time (let's say the users gets the record and then walks off to get a coffee, has a yack with his/her colleagues etc). This is pessimistic locking (typically the UPDATE statement is used a lot in these situations).
As said, in optimistic locking you lock a record at the latest possible moment. In the previous example, when the user starts to update the information the record is not exclusively locked for the user yet, but instead, only when the user hits the save button (or menu option or whatever else you use for that), the program will put a lock on the record and make the changes permanent. Before actually saving the record, the program can make sure whether or not someone else has made changes to the information in the time that our user retrieved the record and hit save (this to prevent possible changes from another user to be lost).
Now, both have their pros and cons, but when you are using event driven programming it is best practice to use optimistic locking. Not just because you can prevent a lot of instances where users are getting the message "record is in use by pete on tty abc01" but there is another pitfall as well....
This pitfall has to do with the fact that Progress transactions are held on session level and not program level. Because you can have multiple windows nowadays, it is theoretically possible that one user has multiple programs open. Say the user gets that record we were talking about before and starts to update it with a pessimistic lock (so locking the record immediately and not just when saved). Then while he/she is doing so, the phone rings and someone wants to place an order. OK, no problem, this is GUI so the user open another window and books the order for customer Jones (and a nice one it is for $10,000.00). Then when that is done, the user closes the order entry window with a smile on his/her face and is about to go back to updating the initial record. But oh no, what does the user see? It is lunch time!!!! Hmmm OK, close the program that was started first, we can update that record later... And what do you thnk? When the user returns that order that was placed is..... GONE. Because the user closed the program the transaction that was started by the first program undoes everything that was done in the time between the user started to update the record and when he/she went off to lunch, which means including that nice 10 thousand dollar order that was booked.
Hmmm I think that was one of the longest stories I ever wrote
. I am sure other people may have their ideas about this too and these things have the potential to become a nice point of interesting discussions...
