IBM Data & AI

 Welcome to the IBM Data & AI Ideas Portal for Clients! 

We welcome and appreciate your feedback on IBM Data & AI Products to help make them even better than they are today!
Before you submit an idea, please perform a search first as a similar idea may have already been reported in the portal.  If a related idea is not yet listed, please create a new idea and include with it a description which includes expected behavior as well as why having this feature would improve the service and how it would address your use case.
IBM Employees:
Clients:
  • Our team welcomes any feedback  and suggestions you have for improving our offerings / products!  This forum allows us to connect your offering / product improvement ideas with IBM product and engineering teams.
  • If you have not registered on this portal please click on the following link and register.  To complete registration you will need to open the email you will receive from Aha to confirm your identity. http://ibm.biz/IBM-Data-and-AI-Portal-Register
Additional Information:
  • The shorter URL for this site is: https://ibm.biz/IBM-Data-and-AI-Ideas
  • To view our roadmaps: http://ibm.biz/Data-and-AI-Roadmaps
  • Reminder: This is not the place to submit defects or support needs, please use normal support channel for these cases
  • Please do not use the Ideas Portal for reporting bugs - we ask that you report bugs or issues with the product by contacting IBM support.

Improve persistent thread concurrency

With the implementation of transactions with persistent threads (like pseudo wait-for-input on IMS) we have been facing some concurrency issues in our site, specially with HPU and batch programs that perform lock escalation. This happens because the persistent thread claims an intent lock on the table/partition and, since our plans have the parameter RELEASE set to DEALLOCATE, never releases it. Programs that try to claim non-intent locks on the table/partition used by persistent threads get a timeout.

Previously the concurrency issues were worse because no utility could run against tables that were acessed by persistent threads, but the problem was solved with the introduction of the PKGREL_COMMIT parameter on v11.

To solve the concurrency issues, we propose a similar behavior as introduced by the PKGREL_COMMIT parameter: dynamically changing the RELEASE parameter (from DEALLOCATE to COMMIT) when a process claims a non-intent lock on the table/partition used by the persistent thread.

 

Itau-Unibanco S.A.

  • Gabriel Durynek
  • Jul 25 2019
  • Need More Information
Why is it useful?
Who would benefit from this IDEA? Any high volume transaction benefits from persistent threads
How should it work?

The proposed solution is to dynamically change the RELEASE parameter on the plan from DEALLOCATE to COMMIT when a process claims a non-intent lock on the table/partition used by that plan. Currently the PKGREL_COMMIT parameter allows that behavior when an utility or DDL is run against tables used by that plan, but we would like for that functionality to be expanded to contemplate any non-intent lock requests.

Idea Priority
Priority Justification
Customer Name Itau-Unibanco S.A.
Submitting Organization
Submitter Tags
  • Attach files
  • Gabriel Durynek commented
    21 Nov, 2019 11:08am

    Hello, Janet.

    Here is a scenario:
    Transaction 1 updates records in the table A. Since transaction 1 is in a PWFI (pseudo wait-for-input) IMS region (the program will never be deallocated) and its plan is bound with the release parameter set to "deallocate", an IX (intent exclusive) lock will be constantly held on the table A. Then, the batch program 2 tries to scan table A with read stability, but since it claims many READ row locks it will try to escalate its locks to a table shared lock. This will cause program 2 to receive a timeout or deadlock message, since the shared lock will never be obtained on table A because of the release parameter on the transaction 1. The same would happen when running a HPU with LOCK YES on table A.

    We would like to know if it is possible to change the behaviour of the release parameter to dynamically change to "COMMIT" on a plan whenever a non-intent lock is requested on an object that has locks held by it. That way, program 2 would claim a shared lock on table A and the release parameter on transaction 1 would dynamically change to "COMMIT", allowing it to release the locks held on table A on the next commit.

  • Admin
    Janet Figone commented
    21 Nov, 2019 12:47am

    Thank you for submitting this Idea. We have reviewed it and would like to ask if you can please send in a detailed scenario, perhaps with messages, or anything providing more details. Thank you.

NOTICE TO EU RESIDENTS: per EU Data Protection Policy, if you wish to remove your personal information from the IBM ideas portal, please login to the ideas portal using your previously registered information then change your email to "anonymous@euprivacy.out" and first name to "anonymous" and last name to "anonymous". This will ensure that IBM will not send any emails to you about all idea submissions