pessimistic logic

Question

to implement the pessimistic locking how to identify/know the data base table is locked or not?

Dave Lewis · Answer

You add a boolean or equivalent "locked" column to the database table that stores your record, or that is linked in some way to your record. You can also include a timestamp and user identification, but those aren't strictly required for it to work. 
 When a user attempts to start an action that could edit the record, you first query the lock. If it's set to true, you inform the user that you're so sorry they're not allowed to use it now. If it is set to false, you let the user continue their action, and the very first thing you do is set the locked column to true. 
 The very last thing your process does after all work on whatever action is complete is to set the lock back to false. 
 On the surface it's very easy. The difficult part is robustly handling all the various different forms of edge cases, such as abandoned processes not permanently locking all users out of a particular record, and other extraneous bits you have to account for when making your solution. But a rudimentary system to get you going isn't much beyond what I described above.

Dave Lewis · Answer

Yes! This makes me realize exactly how to phrase what I intend to phrase. Thank you, Stefan. 
 Every single implementation of pessimistic locking has to be unique to the particulars of the thing you're trying to pessimistically lock, and both what and who you're trying to lock it from. They all have to be different based on your specific goals. 
 My solution: A. Is protected by a Non Disclosure Agreement B. Is too highly technical for me to go into absolutely all the particulars here if I could C. Even if I could remember all of them precisely D. Would therefore be more difficult than making your own even if I could tell you every detail, and finally E. Wouldn't even work for your situation if you could copy it exactly.