We are facing assignment mismatch/flow removal issues in production environment. It happens sporadically. Though some cases are resolved, assignments are not getting removed from user worklist/workbasket.
Changing the /database/maxlockattempts value to 1 is recommended for this issue as per some pdn articles.
Currently we do not have the above parameter set in prconfig. Would it be an impact on other functionalities if we make this change? or is it harmless?
maxlockattempts entry specifies the number of attempts made to open a record in the database before returning a "record is locked" message to the user.
The default value is 3
Setting it to 1 will avoid any race conditions(timing issues) in the application which can potentially allow a stale version of the work object record being committed to the database.
If your audit history of such failed (non-sync) work objects suggested a race condition, then the bug that prconfig change will eliminate allows the product to grab a copy of the stale data and overwrite more current data. As this is the most common race condition in pxFlow & Assignment sync issue, this setting might have been suggested in few cases.
Processes like agents trying to acquire a lock on workobject which is held by a user and by default it retries 3 times(within seconds) to see if it can acquire the lock. If the user closes the work object within the difference of milliseconds agent WINS. Else, it ends up with NO lock which is the same outcome as in setting the entry to 1. -- This is the only difference and this may help you to explore the setting.
Let me know if that clarifies!
Posted: 2 years ago
Posted: 18 Mar 2020 14:06 EDT
Tharinda Madusanka (Tharinda)
Lead Consultant - Technology