Product Documentation
Abstract
To improve concurrency in the presence of user activity, SaveDataAll and CubeSaveData have been reworked to reduce their reliance on highly contentious locks. This change is designed to improve wait times when using SaveDataAll or CubeSaveData.
Content
In previous releases of TM1, SaveDataAll required an IX lock on every changed cube, regardless of Parallel Interaction configuration. Similarly, CubeSaveData required an IX lock on the cube passed as an argument if it had been changed. This lock would conflict with operations, such as data maintenance, making it difficult to run a SaveDataAll or CubeSaveData during periods of user activity. This locking behavior was detailed in the documentation, and strategies to avoid it were suggested.
A new internal synchronization object, the "serialization lock", has been introduced to minimize the set of operations that are likely to conflict with SaveDataAll or CubeSaveData. During a SaveDataAll or CubeSaveData, a cube's serialization lock will be acquired in IX mode, rather than the cube lock itself. In effect, the only other operations that will conflict with a SaveDataAll or CubeSaveData are other SaveDataAll or CubeSaveData operations targeting the same unsaved cube. The SaveDataAll and CubeSaveData operations themselves are still synchronized. The operations cannot run concurrently, but their containing transactions can.
These changes are transparent; no configuration is required.
Transaction Behavior
The documentation notes that "SaveDataAll commits all changes a chore makes prior to calling the SaveDataAll function." A more precise description would be that SaveDataAll concludes with a transaction ending commit. That is, the changes made within a process or chore preceding the call to SaveDataAll are committed along with the serialization of any unsaved objects at the operation's completion. If SaveDataAll encounters a lock conflict during the serialization of unsaved objects, the entire process or chore will roll back, and no changes are committed.
However, in introducing the new serialization lock, and relaxing the locking of the cube itself, it was necessary to add an additional commit in the prelude of the SaveDataAll to maintain consistency. Similarly, CubeSaveData will now begin and end with a transaction delimiting commit operation. That is, the changes made within a process or chore preceding the call to SaveDataAll are committed when the operations is reached.
A subtle ramification of using two commits during a SaveDataAll or CubeSaveData operation is that the window where locks are dropped, as described in SaveDataAll documentation, has been extended, increasing the chances a previously locked object may not be available.
Transaction Log
In the event that a CubeSaveData operation does encounter a lock conflict in the interim between its internal commits, it is possible for a "place holder" directive to appear in the transaction log. The directive takes the form of the CubeSaveData directive, without the relevant information populated. While these messages may appear in the results of a transaction log query, they are ignored during crash recovery, and are therefore considered harmless. Allowing these place holders to "leak" in the rare event of an internal rollback was deemed an acceptable tradeoff for the sake of server robustness.
An example of a place holder directive follows:
#"","20130101010000","**************************************"
This fix is available in TM1 10.2 Fix Pack 2 or TM1 10.1.1 Fix Pack 2 IF1.
Was this topic helpful?
Document Information
Modified date:
17 June 2018
UID
swg27039732