Work Object Lock is not getting released

Are there any negative impacts with reducing the Work object lock time out from 120 minutes to less than 120 minutes ? After changing the time out what are the steps to be performed to get that reflected ?

***Moderator Edit: Vidyaranjan | Updated Categories***

**Moderation Team has archived post**

This post has been archived for educational purposes. Contents and links will no longer be updated. If you have the same/similar question, please write a new post.


Keep up to date on this post and subscribe to comments

November 28, 2017 - 6:26am

There is no such negative impact as such i am aware of .

And post the change, you might need to restart the server once.


However, I stress on utilizing the optimistic locking concept . Here is a good article you can refer

December 12, 2017 - 5:32pm
Response to Santanu

Thanks for the reply. In our application this doesn't need to impact all the users. So, my thought process is to, on demand update the PXEXPIREDDATETIME column in PYSYSLOCK table whenever we get a request from the user to unlock the work object. We'll be providing an additional on the screen for a specific set of users, when that button is clicked we go to the table and update the PXEXPIREDDATETIME column value based on the PXLOCKHANDLE value.

Any issues with this approach ?

December 29, 2017 - 11:45am

I'm not following you.  If the user is releasing the lock, it makes no sense to update the pxExpiredDateTime column.  The lock is being released, so it will not get expired later on.

Did you mean that when the user actually requests a lock, if this button is also clicked, then the expiredDateTime will be set to your smaller value?  I see nothing wrong with this approach, although it does not seem like a "smooth" design to force the end user to interact explicitly with managing locks.