WebSphere Commerce implements serialization mechanisms to prevent certain concurrent updates that could lead to data consistency issues. Although most of the time this serialization is transparent, if while using Javacores or Health Center you see often multiple threads locked, it could be possible to tune the configuration to exclude commands that can run in parallel.
If your site is experiencing performance degradation due to excessive lock synchronization, in Health Center you will see threads in Wait(ActivityLock)or Wait(MemberLock). While ActivityLock protects from multiple threads updating the same Activity (Business Context), MemberLock prevents threads from updating the user object.
The following Health Center screen capture shows a thread waiting for an ActivityLock:
If you are using Javacores, the stack will be similar to the following:
at java.lang.Object.wait(Native Method)
Keep in mind that finding a handful of threads serializing activities or members is common and expected. Performance is only impacted when the event is common, for example when it shows in multiple threads and in most thread dumps or Javacores.
The option to exclude commands from serialization was added in 184.108.40.206 with APAR JR40061: CMVC 211774 - ALLOW THE CLIENT TO CHOSE WHICH CUSTOM COMMANDS THEY DO NOT WANT SERIALIZE. Instead of locking up-front at the beginning of the request, when the noLockControllerCommands option is defined under the Instance node in wc-server.xml, the framework delays locking until right before the command executes. (see the APAR document for details)
Start by adding the noLockControllerCommands snippet with a dummy command in wc-server.xml. Since with this setting locking is no longer done up front, this will help reduce the amount of serialization that is done.
If locking continues, the next step is to add tracing to identify the culprit commands:
- In wc-server.xml under InstanceProperties add <com.ibm.commerce.datatype.AbstractWCLock enableTrace="true" /> to enable tracing. This is only needed during troubleshooting and you shouldn't use in production
- Enable the following traces in the WebSphere Administration Console:
- Hit commonly executed pages while the trace is enabled
- Disable traces (1 and 2)
Using both ServiceLogger and WC_EJB, the traces can help you identify the commands that drive locking:
[11/25/17 14:55:00:116 EST] 000000eb ServiceLogger 3 Command com.mycompany.MyCustomCmdImpl parameters: [param=100]
[11/25/17 14:55:00:116 EST] 000000eb WC_EJB > acquireLock com.ibm.commerce.datatype.ActivityGUIDLock[2080005,false] Entry
You can also see when waits are happening by locating the following line:
[11/25/17 14:55:53:215 EST] 000000eb WC_EJB 3 com.ibm.commerce.datatype.AbstractWCLock acquireLock Waiting 10000 milliseconds.