Previous topic |
Next topic |
Contents |
Contact z/OS |
Library |
PDF
Understanding Contention z/OS MVS Programming: Sysplex Services Guide SA23-1400-00 |
|
Once a lock table entry has became incompatible, XES will begin
to incur significant overhead when processing requests for ANY resource
that maps to that entry. This overhead will continue to be incurred
until the composite state of the lock table entry returns to the shared
or free state. A lock table entry can become incompatible for one
of the following reasons:
Hash Class Contention
Another condition which could result in overhead due to false contention is when two resources with distinct hash values collide at the lock table entry due to the wrap-around condition described previously. In the following example, assume a lock table with 8 entries. User 1 owns a resource with a name of ABC and a hash value of 1. User 2 requests a resource represented by resource name DEF and a hash value of 9. Because the lock table contains only 8 lock table entries, hash value 9 will “wrap-around” and map to lock table entry 1. Once again, while the following example does not result in resource contention and the need to involve the contention exit, the application will incur the overhead required to process requests for resources mapping to a lock table entry that is in an incompatible state. Wrap-Around Condition
In summary, the overhead incurred by XES to process requests that experience contention (whether it be false contention or resource contention) is significant. The performance of your application can be severely impacted as the number of requests that experience contention increases. For this reason, an application should design a protocol which attempts to reduce the likelihood of this occurrence. |
Copyright IBM Corporation 1990, 2014
|