Pega Proactive Notice: Thread Locking

Environments on the following Pega 8.X releases may possibly experience an issue with user or batch sessions becoming blocked or unresponsive:

  • Pega 8.1
  • Pega 8.1.1
  • Pega 8.1.2
  • Pega 8.1.3
  • Pega 8.1.4
  • Pega 8.1.5
  • Pega 8.2
  • Pega 8.2.1
  • Pega 8.2.2

All subsequent Pega 8.X releases include mitigation to this potential issue.

How to avoid the issue

To ensure relevant environments do not incur the thread locking issue, it is recommended that all environments proactively enable a defined configuration setting.

This setting must be configured via prconfig.xml or a JVM command line argument. It cannot be set via a Dynamic System Setting.

Steps to Take

To avoid this issue using a prconfig.xml setting follow the steps described in the Modifying the prconfig.xml file Designer Studio Help article to add the below setting to every Pega node/JVM in the cluster:

<env name=”lac/traditionalLACRegisterSynch” value=”true” />

To avoid this issue through a generic JVM argument add the below string to every Pega node/JVM in the cluster. How to add generic JVM arguments varies between application servers and your environment setup. Contact Pega GCS if you need help.


*IMPORTANT* After implementing the change, an accompanying node restart must be initiated.

Get help

If you encounter issues implementing the prconfig change or have questions about it, post your questions below. The Global Client Support engineers in the PSC will answer your questions or determine and advise if you need to go to My Support Portal to submit a Support Request (SR).


Keep up to date on this post and subscribe to comments

June 27, 2019 - 1:40pm

Are there any Proactive Notices Avaible for 7.x Series (especially after 7.3.x) or 7.4.x, thanks!

June 28, 2019 - 10:08am

There are not, nor are there plans to do so in the future. However, we did recently do a community collaboration to catalog all 7.x critical hot fixes. This provides a single reference for 7.x installs to ensure they are current with the hot fixes Pega has deemed critical for secure and performant deployments.

Brendan | Community Moderator | Pegasystems Inc.

June 28, 2019 - 11:34am
Response to BrendanHoran_GCS

Thank you Brendan. 7.x Link you have provided doesnt have any HFix's mentioned for 7.3.1 or Higher Versions, can I assume,no Critical HFIXs avaiable for those PRPC Versions or the Page not updated?

July 2, 2019 - 11:44am

Let me check into this before providing a definitive response. For now I can tell you that there were none listed at the time we posted this initial draft. It wasn't too long ago, and we do have a recurring action to do maintenance to ensure this list is up-to-date. Let me inquire into this further and if there are any new updates, I'll ensure they get documented and then reply back here.

Brendan | Community Moderator | Pegasystems Inc.

July 11, 2019 - 12:50pm
Response to BrendanHoran_GCS

Hi Brendan,

Did you get hold of the document that you are referring to ?

Thank you.

July 17, 2019 - 1:06pm
Response to PradeepChowdaryP

I've run the latest report for 7.x and the catalog I link to above is up-to-date. There are no critical hot fixes listed after 7.3 for the 7.x release.


Brendan | Community Moderator | Pegasystems Inc.

June 27, 2019 - 11:54pm

Setting : <env name=”lac/traditionalLACRegisterSynch” value=”true” />

When we can get rid of this setting in future? Or the apps in these Pega versions need to live with that forever?

Thank you


June 28, 2019 - 11:10am
Response to mypegasavvy

Hello Savvy one! 

nice question.  No, you won't have to keep this forever.   When you upgrade to the next forthcoming patch release, you could then get rid of this setting.  Changes have already been made in the 8.1.x & 8.2.x patch release streams so that the next patch releases of those that come out later this summer will make the traditional synchronization policy the default


June 28, 2019 - 5:34am

Hi Team,

To avoid the issue, do we need to make both the change as suggested in prconfig & JVM argument, or change in a single place will solve the issue.




June 28, 2019 - 11:06am
Response to NiladriM@Incessant

Hello Niladri

How are you? 
You only need to change one or the other.  Both ways control the same setting. You can choose the one that best fits your deployment. If it's easier for you to change the config file, then do that.  Or if it's easier to control command line args, then choose that route


June 28, 2019 - 11:38am
Response to NiladriM@Incessant

Hello Niladari- We were suggested by one of Pega's performance tuning expert, to remove all the settings out of prconfig file and keep them as DSS's, if any JVM args required, add them at the JVM level. 

We havebeen following that approach past one year and our applications running stable. I would suggest to go the same way. 




July 5, 2019 - 2:36am

Thanks friend, yes I also think the same to update JVM instead config file.

June 28, 2019 - 1:08pm


Is this addressed in pega 8.2.1 version or we have to do this .

is there any specific error related to this setting ?

June 28, 2019 - 3:19pm
Response to RanjithkumarC

Hello Ranjithkumar

The problem can occur in 8.2.1. That's why this notice is being communicated.

Please take the appropriate action for your deployment.


July 2, 2019 - 3:18pm

There is an optimistic way to detect DEAD locks by using ThreadMXBean, which provides a method called findDeadLockthreads() which returns id of all those threads which are in deadlock and waiting for each other to release monitor or acquire lock. 


ThreadMXBean threadMBean = ManagementFactory.getThreadMXBean();




And using this approach we can kill the DEAD locks by doing further optimization capability of System Cleaner agent to do above monitor and kill the dead locks to prevent from system failure.


Could you review this approach with Engineering Team ?




Certified J2EE / Pega CLSA

July 5, 2019 - 10:17am

>>> EITHER <<<

prconfig.xml should have to following entry 

<env name="lac/traditionalLACRegisterSynch" value="true"/>

>>> OR <<<

JVM argument should be set as


September 4, 2019 - 9:59pm

Has this issue been resolved in 8.2.3 version?

September 5, 2019 - 12:32am
Response to ADIKARIB

Hello Adikarib

YES, it has!   If you upgrade to 8.2.3, this problem will not occur


September 6, 2019 - 12:50pm
Response to eiset

Thank you

September 23, 2019 - 11:30am
Response to eiset

How about in 8.1.6 environment? Was it got resolved.

September 23, 2019 - 2:09pm
Response to RajaniKanth

Hello Rajani

How are you?

Yes, it's resolved in 8.1.6.  it's been fixed in every patch release cycle for 8.1, 8.2, & 8.3