D
dbeavon
Guest
@PhilF Thanks for the tip. I have used record locking in the past as well. One of the problems is that the code I'm synchronizing is local to a *single* process (_mproapsv) and it seems overkill to reach out over the network to a remote database (via client/server) in order to synchronize two threads in a single local process. Another issue with this approach is that the exchanging of control over a record lock takes a very long time. Locks are withheld from the client that is waiting, even after the lock is released. I think this is because of the behavior of the NmsgWait startup parameter. You can read more about that in the following thread: community.progress.com/.../56505 The only way I found to release the utility table more quickly to another waiting client is to implement custom code that continually spins and tries to lock with "EXCLUSIVE-LOCK NO-WAIT NO-ERROR". This involves a lot of custom programming that shouldn't be needed, and is wasteful on CPU and network.
Continue reading...
Continue reading...