The most common root for this problem that I've seen is that the application "accidentally" generates share locks because the developer(s) did not understand the concepts of transaction and buffer scope - or they just did not care ...
At the end of a transaction, if the buffer scope is larger than the transaction Progress will downgrade the EXCLUSIVE-LOCK automatically to a SHARE-LOCK. Anybody else that's attempting to lock the record exclusively will run into the error message you've seen. In almost all cases I've seen where the buffer scope is larger than the transaction scope, it is because the same buffers that are used within the transaction to update the database are referenced outside the transaction with a free reference (a FIND before the transaction for example). Mostly it's because of sloppy developers using the standard record buffer in all cases instead of working with named buffers on purpose to avoid the whole thing in the first place.
A NO-GO which all developers should hammer into their brains: Never, never, never ... never use the same buffer inside and outside of a transaction.
The only way this can be solved is to change the application code so that the application (or should I say, the developers) behaves to support multi-user concurrency ...
Regards, RealHeavyDude.