TM1.Lock.Exception Throwing IXConflict on object }DimensionProperties
Posted: Wed Mar 15, 2023 5:14 pm
Hi,
Seen on version 2.0.9.15 (developed on this release so I can't tell if this is new).
Have a muti-threaded load routine that works exactly as intended, except first use after a server restart.
After a server restart the first call to the job that spawns all the independent RunProcess loads, gets hit with a lock and rollback as below.
17696 [a7] DEBUG 2023-03-14 09:05:08.572 TM1.Lock.Exception Throwing IXConflict on object }DimensionProperties
17696 [a7] DEBUG 2023-03-14 09:05:08.572 TM1.Lock.Exception CommitActionLog::Rollback: Called for thread '17696' of user 'R*ChoreName' executing request 'POST /api/v1/Processes('JobName')/tm1.ExecuteWithReturn'.
This appears to happen after all the independent load threads have been launched, probably at the commit stage of the TI. The rollback and relaunch results in twice as many jobs being launched, with resulting havoc....
I’ve been through the script with a fine tooth comb and the closest suspect I have to something that could cause a problem is a set getting created. I don’t believe this enough on it’s own to cause a problem, particularly because it works properly the rest of the time.
This reminds me of a bug from way back where we needed to use AddCubeDependancy to create the relationships between ruled cubes and attributes cubes, as they were skipped over on start-up. This also used to block multi-threaded activity.
There is no mention in the logs of anything being created at the point of the lock. (Any ideas of what I could turn up in the log properties here?).
I’m just going to write a job that creates and deletes a sub against all the dimensions at the top of the job and see if this resolves. This is a bit blunt and I am wondering if anyone has hit this before or has ideas on how to narrow down where the issue is occurring.
Just to be clear though, the multi-threading works perfectly except on first use. I don’t believe there is a basic issue with the build.
TIA for any ideas
Cheers,
Seen on version 2.0.9.15 (developed on this release so I can't tell if this is new).
Have a muti-threaded load routine that works exactly as intended, except first use after a server restart.
After a server restart the first call to the job that spawns all the independent RunProcess loads, gets hit with a lock and rollback as below.
17696 [a7] DEBUG 2023-03-14 09:05:08.572 TM1.Lock.Exception Throwing IXConflict on object }DimensionProperties
17696 [a7] DEBUG 2023-03-14 09:05:08.572 TM1.Lock.Exception CommitActionLog::Rollback: Called for thread '17696' of user 'R*ChoreName' executing request 'POST /api/v1/Processes('JobName')/tm1.ExecuteWithReturn'.
This appears to happen after all the independent load threads have been launched, probably at the commit stage of the TI. The rollback and relaunch results in twice as many jobs being launched, with resulting havoc....
I’ve been through the script with a fine tooth comb and the closest suspect I have to something that could cause a problem is a set getting created. I don’t believe this enough on it’s own to cause a problem, particularly because it works properly the rest of the time.
This reminds me of a bug from way back where we needed to use AddCubeDependancy to create the relationships between ruled cubes and attributes cubes, as they were skipped over on start-up. This also used to block multi-threaded activity.
There is no mention in the logs of anything being created at the point of the lock. (Any ideas of what I could turn up in the log properties here?).
I’m just going to write a job that creates and deletes a sub against all the dimensions at the top of the job and see if this resolves. This is a bit blunt and I am wondering if anyone has hit this before or has ideas on how to narrow down where the issue is occurring.
Just to be clear though, the multi-threading works perfectly except on first use. I don’t believe there is a basic issue with the build.
TIA for any ideas
Cheers,