Kbase P3126: Why is locking behavior different between shared memory connections and client server connections?
| Autor |
Progress Software Corporation - Progress |
| Acesso |
Público |
| Publicação |
12/8/2006 |
|
Status: Verified
GOAL:
Why is locking behavior different between shared memory connections and client server connections?
FACT(s) (Environment):
Progress 9.x
Progress 8.x
OpenEdge 10.x
FIX:
The unlock behavior on a network client has been different from the unlock behavior on a shared memory client for a long time.
The reason is that unlock network messages are very expensive. They have caused as much as triple the time to do a fetch (their one-way nature has caused network slow-downs). So we will not be changing this behavior.
This is due to necessary optimization of record unlocking found only in the network cases.
Network unlock messages are small one-directional messages -- which happen to be the slowest possible type of TCP/IP message, and we have to avoid them at all costs. So we batch them up and do them in a delayed way which does not happen for shared memory cases. We could use the same code in both places, but it could slow up network applications by a factor of as much as 3.
If the *normal* scenario is used (get a lock, use the locked record, release the lock) the difference in behavior is not noticeable, so we feel that the trade-off of far better performance balances the small inconsistency.