Risks of using Multiple Commit Mode

[Emixam]

Hello,

I have a daily chore that usually takes 1h20 to run. The following processes are executed:

1. Update metadata
2. Update security (Cube, Dimensions and Element security)
3. Security Refresh
4. Load data

I also have a SaveDataAll that is executed every hour.

However, multiple times a week, the chore is executed 2 or 3 times in a row. I suspect that a lock conflict happens and then a rollback is trigged and the whole chore is executed again. Sometime, there is user in other parts of the world who try to access to TM1 and I also feel like it might affect the locks.

I'm thinking about changing the property of my chore to "Multiple Commit" to see if it fixes the issue.

My questions are:
1- What are the risks of using Multiple Commit instead of single commit ?
2- Any idea what causes the the chore to run 2 or 3 times in a row ?

Thanks and have a good day

ps: I will use the }bedrock.chore.execution.check TI to exclude SaveDataAll during the daily chore.

[ykud]

2- Any idea what causes the the chore to run 2 or 3 times in a row ?

I'm a big fan of adding
log4j.logger.TM1.Lock.Exception=DEBUG, S1
to the tm1s-log.properties file as it'll show you the lock contention and will say whether a chore is rolled back.
I'd guess that SaveDataAll chore is trying a server-wide lock and causing the chore to restart -- I've seen it quite a few times.

1- What are the risks of using Multiple Commit instead of single commit ?

The only one that comes to mind is that other processes or users be able to see committed values in one of the steps before the whole chore completes. I generally much prefer multiple commit to decrease locking

ps: I will use the }bedrock.chore.execution.check TI to exclude SaveDataAll during the daily chore.

I always see and use a cube with a isChoreRunning flag used instead, with the flag populated in the first step of a multi-commit chore.

Cheers,
Y

[Emixam]

Thanks Ykud, it's really helpful !