What is Workspace:
Whenever a user logs into the administrative console, or uses wsadmin scripting to make a configuration change, the changes are stored in the workspace. When a user uses the ConfigService configuration service interface of the Java application programming interfaces (APIs), the user specifies a session object that is associated with the workspace in order to store the changes. Only when the user performs a save operation under the administrative console, wsadmin scripting, or the Java APIs are the changes propagated and merged with the master configuration repository.
For each administrative console user or each invocation of wsadmin scripting, the application server creates a separate workspace directory to store the intermediate changes until the changes are merged with the master configuration repository. Users of the Java APIs use different session objects to decide where the workspace directory resides. Both the administrative console and wsadmin scripting generate user IDs randomly. The user IDs are different from the user IDs that you use to log into the administrative console or wsadmin scripting. The Java APIs can either randomly generate the user ID or specify the user ID as an option when creating the session object.
Workspace keeps track of context and file states whenever a caller does an add / delete / extract / update using Workspace APIs.
Default wstemp directory location: %user.install.root%\wstemp\
where %user.install.root% is %WAS_HOME%\profiles\<profile name>\
Changeable by setting following JVM custom property:
Change the JVM custom property through the administrative console by setting the JVM property as a name-value pair on the Custom properties page.
Under Console > Click System Administration > Deployment manager > Java and Process Management > Process definition > Java Virtual Machine > Custom properties.
Workspace directory location
Workspace generates the following files to keep track of the status of workspace, context and file:
- “.workspace_”<session id>
Under %user.install.root%\wstemp\<user id>\workspace directory to distinguish which session of the user works on the workspace.
This file contains a runtime call stack information from WorkSpaceManagerImpl.createWorkSpace(Properties)
Under each <context type>\<context name> subdirectory of workspace, keep the status of the files being accessed.
- <File Name>".copy": keep the digest of the file being extracted.
- <File Name>".current": keep the original copy of the file if merge is needed for this document. Only serverIndex.xml will be merged at this time.
Directory types generated under wstemp folder
- Script*: created by a wsadmin script;
- anonymous*: created by client that pass a null workspace/session id.
- -NNNNNNNNN: created by Admin Console
It is the responsibility of the caller to remove the workspace session. It is better that the caller creates a session and then discards the session when finished. Each workspace is associated with a session object.
This one always creates a new unique session. The id of the session will be anonymous+current-time-in-millisecs. The following two lines will result in creation of a new unique workspace:
Session session = new Session();
So, every time a new session object is created this way and used, a new unique workspace directory will be created. Therefore, these workspaces should be removed by calling configService.discard(session) method or workspace.remove() method.
2. Session(id, resuse)
This one creates a new session based on the supplied id. If there is already a workspace created for that id, the same workspace will be used. However, it is not true if the reuse flag is set to false. If the reuse flag is set to false, a new session with id+current-time-in-millisecs is created.
- The following two lines will result in creation of a new workspace if the corresponding workspace directory does not exist:
Session session = new Session("myWorkspace", true);
The workspace must be removed by calling workspace.remove() or configservice.discard(session).
- The following two lines will result in creation of a new unique workspace
Session session = new Session("myWorkspace", false);
Note: Every time a session object is created this way, it results in a new unique workspace. Therefore, all the workspaces created this way should be removed. If the caller code is not discarding the session it created, then the size of the wstemp folder will grow and eventually it can cause an OOM (out of memory) condition of dmgr or server depending on your setup.
One can turn on the following trace string either on deployment manager (or) on base application server depending on the type of setup to review the caller creating the workspace:
Current trace specification = *=info:com.ibm.ws.sm.workspace.impl.WorkSpaceManagerImpl=all
With above trace string is enabled one can see following logging in the trace.log file:
In the example, I used the case "anonymous*: created by client that pass a null workspace/session id"
[5/9/14 9:00:15:241 NZST] 00000001 WorkSpaceMana > getWorkSpace, UserID: anonymous1399582815240, SessionID: null, create workspace if not found: true Entry
[5/9/14 9:00:15:241 NZST] 00000001 WorkSpaceMana 3 Call stack info of createWorkSpace(prop), workspace id anonymous1399582815240:
<----- new workspace anonymous1399582815240 is created ----->