Support Article
First case with a case prefix has lock issue on UniqueID table
SA-40120
Summary
The first case with a case prefix has a lock issue on UniqueID table.
The Smart Investigate framework is being used in application development. The case prefixes are of the format M-yymmdd-nnnnnn so a new case prefix will be created every day for a case. For example, a message case created today looks like M-170607-000001. When the first message case of the day is created, the case prefix is added to the UniqueIDs database table. The user is seeing errors in the log every time a new case prefix is added to the UniqueIDs table; however, the cases are getting created properly.
When the user had exception handling enabled on automated case creation, they found their activities were skipping some important steps because of the error in processing.
Error Messages
Save, Delete or Commit has failed because lock "DATA-UNIQUEID !G-170607-" is not held
Steps to Reproduce
Create the first case of a case prefix.
Root Cause
A defect in Pegasystems’ code or rules. It is necessary to add a lock to the lock table in order to create the new prefix.
Resolution
Perform the following local-change:
For the rule PegaSI-Work-.GenerateID, change this:
if (pgUniqueID != null)
{
// Copy this higher value over to an entry without an organization
pgUniqueID.putString("pyOrganization", "");
tools.getDatabase().save(pgUniqueID, false, false);
nextID = tools.getDatabase().getDataUniqueID("", prefix, ""); //use prefix and no suffix
}
to this:{
// Copy this higher value over to an entry without an organization
pgUniqueID.putString("pyOrganization", "");
tools.getDatabase().save(pgUniqueID, false, false);
nextID = tools.getDatabase().getDataUniqueID("", prefix, ""); //use prefix and no suffix
}
if (pgUniqueID != null)
{
// Copy this higher value over to an entry without an organization
// Since we will be overwriting the entry we just created, we will need a lock
pgUniqueID.putString("pyOrganization", "");
if (tools.getDatabase().getLockManager().lock(pgUniqueID, false))
{
tools.getDatabase().save(pgUniqueID, false, false);
tools.getDatabase().getLockManager().unlock(pgUniqueID, false);
// Now get the next ID based off the old pyOrigOrg's last reserved value.
nextID = tools.getDatabase().getDataUniqueID("", prefix, ""); //use prefix and no suffix
}
else
{
myStepPage.addMessage("Unable to lock unique id record to carry over last reserved id with organization.");
nextID = "";
}
}
{
// Copy this higher value over to an entry without an organization
// Since we will be overwriting the entry we just created, we will need a lock
pgUniqueID.putString("pyOrganization", "");
if (tools.getDatabase().getLockManager().lock(pgUniqueID, false))
{
tools.getDatabase().save(pgUniqueID, false, false);
tools.getDatabase().getLockManager().unlock(pgUniqueID, false);
// Now get the next ID based off the old pyOrigOrg's last reserved value.
nextID = tools.getDatabase().getDataUniqueID("", prefix, ""); //use prefix and no suffix
}
else
{
myStepPage.addMessage("Unable to lock unique id record to carry over last reserved id with organization.");
nextID = "";
}
}
Because of the nature of the stored procedure that is used to generate unique ids, the first id of each day will start at XXX-000002. This is not a bug and should not cause any business hardship.
Published August 26, 2017 - Updated October 8, 2020
Have a question? Get answers now.
Visit the Collaboration Center to ask questions, engage in discussions, share ideas, and help others.