IBM Data and AI

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

We welcome and appreciate your feedback on IBM Data and 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.

  • Avatar32.5fb70cce7410889e661286fd7f1897de Guest
  • Jul 25 2019
  • Under Review
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.

Customer Name Itau-Unibanco S.A.
  • Attach files
  • Admin
    Janet Figone commented
    16 Oct 11:37pm

    Hello, Yes. The additional input you provided has been shared with the Db2 for z/OS developer reviewing this idea. We will let you know if any additional information is needed. Thank you.

  • Avatar40.8f183f721a2c86cd98fddbbe6dc46ec9
    Guest commented
    14 Aug 09:37pm

    Hello, Janet.

    Did you see our last update on November 21, 2019 ?

    Is it enough to allow analysis proceed or do you need/want more information ?

    IDEA is NEED MORE INFORMATION.

    Could you let us know, please ?

  • Avatar40.8f183f721a2c86cd98fddbbe6dc46ec9
    Guest 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