TM1 Forum

tm123 wrote: Yes, that exact code causes locking ( the only way it does not create locking is if Cube Logging for the cube }CubeProperties is ON, so in that case TM1 will not commit the change to the cube yet ). So just make sure that in the }CubeProperties cube, the setting for the cube }CubeProperties is NO and try it again, I would be surprised if you still can run your TI in parallel

Does not make a difference in my testing. I would've been very surprised if it did. The only thing affected by cube logging is if a record gets written out to the transaction log. The only side effect I've ever seen is the performance drop from writing out large number of records.

Hi Tm123

So you are saying that turning cube logging ON for }CubeProperties means that things run in parallel. Presumably your concern is then that logging may be off when a user enters data and there is therefore no transaction log to recover from in the event that the server fails. Have you checked that this is the case? I am wondering if the onion skin approach of PI means that in practice that logging is only off for the session that has turned it off? I don't have the time to experiment myself but it might be worth verifying.

We have a system here that uses a mapping approach that sounds similar to the one that you have. Do you by any chance have a Technical Dimension and a Technical cube? I replaced this with an alternative approach which involves cascading all mappings to the base level and mapping everything via rules at the base level. It is working well, and brings added bonuses in terms of traceability of the mappings. However, we are finding that the Technical dimension approach has been used in lots of places in the system, and in many cases simple consolidation could have replaced the mapping. That may not be true in your system but it is worth considering.

Regards

Paul Simon

BrianL wrote:

tm123 wrote: Yes, that exact code causes locking ( the only way it does not create locking is if Cube Logging for the cube }CubeProperties is ON, so in that case TM1 will not commit the change to the cube yet ). So just make sure that in the }CubeProperties cube, the setting for the cube }CubeProperties is NO and try it again, I would be surprised if you still can run your TI in parallel

Does not make a difference in my testing. I would've been very surprised if it did. The only thing affected by cube logging is if a record gets written out to the transaction log. The only side effect I've ever seen is the performance drop from writing out large number of records.

Look at my testing scenario:

I have a TI Process with your code in Prolog and Epilog, and I login twice and run the TI.

1. Scenario_1: Logging for }CubeProperties cube if OFF. The second instance of the process in on wait 2. Scenario_2: Logging for }CubeProperties is ON. Both instances run in parallel 3. Scenario_3: Turned Off again Logging for }CubeProperties We downloaded FP3 and installed in a POC environment and I will try there, but this has been like this since 9.5.2

Thanks

Are you using CubeSetLogChanges or CellPutS to }CubeProperties?

I believe it is now fixed in all versions of 10.2.2 but earlier CubeSetLogChanges could lock whereas CellPutS to }CubeProperties was non-locking for PI.

Oops, my bad.

I forgot that an empty value in }CubeProperties for the LOGGING property is the same as a YES value, so my previous test was wrong.

I do in fact see the IXC contention when using CubeSetLogChanges().



HOWEVER, changing that to CellPutS does not seem to show the same IXC contention.

Yes, replacing CubeSetLogChanges with CellPutS seems to work, but IBM technical support guy does not agree with that. They're saying that by design, if 2 processes are trying to update the same cell at the same time, TM1 will put a lock on the second process.

I showed him how it works when Logging for }CubeProperties is YES and also I showed him how it works if I replace CubeSetLogChanges with CellPutS but he is saying it should not let you run the processes in parallel

tm123 wrote: IBM technical support guy does not agree with that. They're saying that by design, if 2 processes are trying to update the same cell at the same time, TM1 will put a lock on the second process.

Well, that's just plain wrong.

Parallel Interaction (PI) is a server configuration that improves response time of writing data by removing lock contention resulting from concurrent cube data access (when the system reads data or when the system writes data). When enabled, Parallel Interaction changes the Cognos® TM1® Object Locking model so that write operations are not blocked by concurrent data read or data write operations to the same cube (or dependent cubes based on rules).

-http://www-01.ibm.com/support/knowledge ... ction.html

Not sure why CubeSetLogChanges behaves differently. Maybe it's writing out the entire }CubeProperties.cub file when transaction logging is disabled, while CellPutS does not trigger the cube file save?

BrianL wrote:Not sure why CubeSetLogChanges behaves differently. Maybe it's writing out the entire }CubeProperties.cub file when transaction logging is disabled, while CellPutS does not trigger the cube file save?

Just think about it, with PI switched on each TI only commits data at the end. Doing a CellPutS into }CubeProperties works, but only for the TI that is invoking that statement. Until the TI finishes and commits no other thread will know that logging settings have been changed. However, when you execute CubeSetLogChanges you probably expect an immediate effect for all threads. That cannot be done unless you do something special to inform other threads that the setting is changing and this requires a lock, no surprise there. Just writing a value to a cube would not be visible outside the one process until it finishes, which could be an unspecified length of time later.

In that respect CubeSetLogChanges is quite similar to SaveDataAll and CubeSaveData - it's forcing an early commit of changes: "[T]he 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." CubeSetLogChanges does in fact seem to serialize }CubeProperties to disk (tried this just now with 10.2.0 FP2), so your observation is spot on.