I need to verify how sessions are to be released/disconnected for custom workflow tasks with the 2 signatures below:
1. A workflow task based on a custom bpm activity template:
public class StatisticsLoggingActivity extends WorkflowMethod {
public int doTask(IDfWorkitem workItem, IDfProperties activityParameters, PrintWriter printWriter) {
1. I am currently using workItem.getSession() to access the session
2. I DO NOT execute any type if session disconnect or release at the end of my task. If I do, I get an error that you cannot disconnect a dynamic session handle.
PLEASE confirm that, for this type of workflow task, I am not supposed to disconnect or release the session from the workItem.getSession() method.
2. A workflow task executing a dm_method:
public abstract class ServerMethodBase implements IDmMethod {
public void execute(Map parameters, OutputStream output) throws Exception {
1. I am currently getting a session from the sessionMgr as follows:
try {
sessionMgr = DctmSession.createSessionManager(_docbase, _user, _ticket);
session = sessionMgr.getSession(_docbase);
2. I am currently releasing the session as in the finally block as follows:
} finally {
if (session != null) sessionMgr.release(session);
}
PLEASE confirm that, for this type of workflow task, this is the correct way to GET and RELEASE dctm sessions.
I am asking because we have recently increased the workflow default workflow agents from 3 to 4 and after about 6 hours of running (under heavy workflow load), we ran into the following error and want to make sure our code isn't causing this. NOTE. Prior to the increase in agents, as far as I know, we haven't seen this error before so my assumption is that our code is fine, however, I figure it was worth getting confirmation.
DM_SESSION_W_EXEC_POOL_FULL
Severity: WARNING
Message Text: Unable to launch process to perform deferred updates to objects, because the execution context pool is currently full. The updates will be performed later.
Cause: Fail to lauch process because of full execution context pool.
Action: If this's been happening a lot, increase concurrent_session in the server.ini.
