Links may not function; however, this content may be relevant to outdated versions of the product.
Troubleshooting: "Failed to resave page" with ReSaver Servlet
When running the V4.2 ResaverServlet, messages similar to the following may occur:
Resaving instances of AtPega-Task (Class: 1 of 9) Saved 0 instances of AtPega-Task Resaved 0 instances for AtPega-Task (0 of 0) Resaving instances of AtPega-Task-Support (Class: 2 of 9) Saved 0 instances of AtPega-Task-Support Resaved 0 instances for AtPega-Task-Support (0 of 0)
Resaving instances of AtPega-Task-Support-Request (Class: 3 of 9)
Error: Failed to resave page: Database-LockFailure-LockLost ATPEGA-TASK null (Key: Resave)
Error: Failed to resave page: Database-LockFailure-LockLost ATPEGA-TASK SR-1 null (Key: Resave)
Error: Failed to resave page: Database-LockFailure-LockLost ATPEGA-TASK SR-10 null (Key: Resave)
Error: Failed to resave page: Database-LockFailure-LockLost ATPEGA-TASK SR-100 null (Key: Resave)
Update: This issue is resolved in V5.1+.
The Resaver Servlet opens each instance of a specified class and resaves them. In V4.2SP4 and earlier, this process does not involve locking any of the instances - just an open followed by a resave. However, as a result of security enhancements in V4.2SP2 SmartBuild, classes that have locking enabled must have a lock in order to save them, so errors occur.
Workaround for V4.2SP2, V4.2SP3, and V4.2SP4:
By default, the
pegarules.xml file sets the transactionalLockManagement entry to
Advanced, which enables the enhanced security. Setting this entry to
Standard allows the system to save all classes without requiring locking.
NOTE: If the default setting is enabled, the entry may not be in the
pegarules.xml file. To change the entry to
Standard, add the following line to the database section of the
<entry key="storageVersion" value="6"/>
<entry key="transactionalLockManagement" value="Standard"/>
Important: If you make this change, then be certain to:
- Stop and restart the Process Commander server
- Change the
pegarules.xmlfile back to the
Advancedsetting after you finish using the ResaverServlet servlet.
If the you don't change the setting, then the data integrity of the system data is at risk.
Resolution For V4.2SP5:
Check the Lock instances check box.
If this check box is selected, then the ResaverServlet locks any (lockable) class instance that it is saving. Checking this box makes the ResaverServlet processing safer (although slower); you can run it while others are using the server.
If the box is not checked, then the ResaverServlet forces all instances to be saved without a lock. As a result, if a user is updating an instance while the ResaverServlet is running, then the user's updates may be overwritten.
Accordingly, as a best practice, check the Lock instances box.
Previous topic Refactoring unsupported symbolic index syntax for value lists and page lists Next topic Troubleshooting: "Failed to resave page" with Resave Table feature