Process A is a control process that runs various sub-processes, mostly through the ExecuteProcess function. However, one of the first things we need to do as part of the process is to insert a temporary element into one dimension, Versions, and add the members of a dynamic subset of the Versions dimension to that consolidation. We then use that consolidation element in a subsequent subset for datasource view. So, I decided to explore making the modification by running the process with TM1RunTI (ExecuteCommand) to make the dimension modifications in order to prevent contention locks for all users (Versions dim is HEAVILY used throughout the model).
And got slammed with a contention through a READ lock on a seemingly unrelated dimension. Here is the order in which things are happening:
- Process A reads the server instance from a }System_Environment cube to retrieve the TM1 instance to pass along to TM1RunTI (-connect parameter). This cube contains the Counter dim (dimension with elements 1...N)
- Process A then calls TM1RunTI, passing along the connection parameter read from the cube to execute Process B.
- Process B Prolog checks for the consolidation element and adds it (DimensionElementInsertDirect). If the C element exists, it removes its components (DimensionElementComponentDelete)
- Process B Prolog then creates a subset and adds the consolidation element to it
- Process B Prolog then creates dynamic subset of the elements designated to be components of the consolidation. Said subset is converted to a static subset.
- Process B Prolog then adds the members of the second subset to the C element referred to in step 3. (DimensionElementComponentAdd)
- Process B's Epilog is then supposed to execute a process that updates a process statistics cube we use and exits.
Code: Select all
strTimeStamp = TIMST(NOW, '\d:\h:\i:\s');
strOutput = 'Checkpoint 5';
strCommand = EXPAND('cmd /c echo %strOutput% >>"%strOutputFile%"');
ExecuteCommand(strCommand, 0);The lock seems to be preventing the PROLOG from completing. From the log:Checkpoint 1
Checkpoint 2
Checkpoint 3
Checkpoint 4
Checkpoint 5
Which happens to be the last entry in the log until I have to shut it down to get out of the contention.1217636 [c] DEBUG 2017-06-01 17:01:32.823 TM1.Lock.Exception Contention encountered attempting to acquire lock (0x000000000243A6C8) on object [Dimension "Counter", addr=0x000000000243A610, index=R-232] in IX mode at ..\tm1_r7s\TM1DimensionImpl.cpp:8931 during function 'ProcessExecuteEx'.
Entering wait state 'IXCur'.
Blocked by the following 0 threads:
All that to ask this: why is a read on a cube containing the counter dimension preventing modifications to another dimension? And by the way, this runs fine IF instead of using TM1RunTI, ExecuteProcess is used OR the environment for the -connect parameter is hard-coded to avoid reading the }System_Environment cube. I will appreciate any insight.
Other questions: Is there a method to avoid the lock contention on the unrelated dimension without hard coding the environment? Am I chasing a rabbit? Why do I always grab precisely 10 M&Ms from the jar?
I am going to try changing the cube from }System_Environment to System_Environment to see if that is causing all this gnashing of teeth and pulling of hair.
