Hi, I am looking to see is there any specific recommendation around how far one should go while changing the default case lock timeout from 30 min to more. currently it is set to 3 hrs, but client wants it to be 8 hrs due to the nature of the work processing.
I understand the aforesaid can be taken care via training and all where users can be educated to hit save periodically. However, I am interested to know what could be some of the implications (if any) on DB server and App server if we go beyond this time.
In my opinion, technically, I do not see any issue from Pega perspective per say, neither from DB perspective. However, would there be any significant impact on tomcat other than the fact that if session is active for 8 hours, the memory would be allocated for that requester for 8 hours?
I don't think that is relevant exactly. However, as per the business processes, sometimes users are supposed to add more than 100 assets into a deal, then it would go through a decision approval process. adding 100 assets with all details take time....definitely more than 30 mins...
there are many ways to handle it, one way is from design perspective but that;s a long shot.. for a quick turn around 8 hour is being evaluated . as also said before, I am interested to know if there is any implication on App server memory utilization due to this.
Unless you also tweaked Requestor timeout, whole requestor session will be passivated way before that, freeing up the server memory. But, if your requestor timeout is set to end the session without passivation (<env name="Initialization/PersistRequestor" value="never" />), that would defeat the purpose.
"I was under the impression that the locking mechanism and passivation were unrelated" - Yes, they are unrelated, and that's the reason why requestor session will be passivated (or deleted, depending on the aforementioned setting), irrespective if the case is locked or not. Passivation will alleviate OP's concern about the resource/memory usage.