Managing Multiple, Asynchronous Lock Requests

Your program can issue multiple, asynchronous requests to obtain the same lock. Each request is processed independently. The order in which requests are processed might differ from the order in which they are submitted. Furthermore, due to the nature of asynchronous processing, the order of certain events could deviate from what you would expect. For instance:

Your notify exit could receive control to inform you of contention for a lock you requested before you are informed that you have obtained the lock.
Note: You own a lock you have requested only when you are informed (in the manner specified on your IXLLIST invocation) that your request has completed successfully. Unless you have received this confirmation, you cannot assume you hold the lock.
Your notify exit could receive control to handle contention for a lock you no longer own. If you have, in the recent past, obtained and released the same lock you own currently, your notify exit could receive control due to contention arising from your previous instance of lock ownership.

To handle situations like these correctly, you should use the LOCKDATA and REQDATA parameters to pass any information your exits will require to determine if they need to take action. Your exits must also be prepared to handle cases, such as those listed above, where they receive control but need not take any action.

If you request a lock that you already hold (perhaps on behalf of a different user), your request is treated like any other user's request for that lock; it is placed on a queue behind any existing requests for that lock.

Important: A deadlock will occur if the unit of work responsible for releasing a lock is suspended while waiting to obtain the same lock.