Dave, I used pessimistic locking only once (in something I inherited from a less experienced Access person) and then quickly decided to find another way because it was a P.I.T.A. for sure.
My issues on VMS involved ORACLE deadlocks, and there, at least, the user would get a "deadlock" message because ORACLE had some pretty good algorithms for detecting that.
Using a SHAREBASE back-end and VMS front-end, I was able to trace back network connections to see that process X and process Y were hibernating for database wait states. I warned the developers enough when jobs would hang each other up that I was able to help them formulate rules about the order of explicit locking. If every lock is given a "preferred order" in a document that we can publish, and if every locking case ALWAYS uses the same order of locking, a "deadly embrace" type of deadlock can't occur. (Other resource waits CAN occur, sadly.) But I digress.
@hfsitumo2001 - Just so you will understand more clearly - if you are sharing data in a common back-end file, ALWAYS (when using Access) choose to minimize the time during which the data would potentially be locked. This means choosing either Optimistic locks or No locks. There are options for these on forms and queries. I believe that Domain Aggregate functions are always "No locks" but can't swear to that. However, they are usually quite safe and won't interfere with anything. SELECT queries that aren't being used incidentally for updates can also be set for No locks. Queries that do any kind of data modifications should be set for Optimistic locking. (NOTE: My OPINION and preference is "Optimistic Locking" in that case.)
EDIT: I see that Pat has also commented in favor of Optimistic locking.