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.
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.
|Customer Name||Itau-Unibanco S.A.|
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 "firstname.lastname@example.org" 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