TM1 Forum

Hi,

We are getting mysterious dimension locks where a user takes an intent to write on a dimension during a simple cube view or spreadsheet refresh (we think). This appears to be erratic.

Is there a list anywhere of operations that will take a write lock on a dimension?

The users concerned do not have write access to any objects.

This is causing some big many minute queues in our instance (10.1.1) and we're stumped as to what is triggering it. When they get to the front of the queue the action is completed very quickly.

Any clues or pointers?

We've checked custom roll-ups in the cube viewer and "subsets as consolidations" and been unable to reproduce. One user did say they were doing this during the rough period the lock took place, others insist that they don't use it.

No TIs in action when this happens, although some do queue behind the user.

Cheers,

I know it shouldn't be an issue but are there any MDX subsets in the views / templates being used?

Also what are the messages you're seing in top??

Hi Jim,

I've not picked up any MDX in the spreadsheets that I've been given by users who have triggered the issue. I think it is very unlikely that there is anything present.

Top message is as follows.

State - Wait:IXCur(MI_Entity)-(Dimension)
Function -
Obj Lock Satatus - (Dimension)
User Lock Status - (R)144(IX)4(W)0

Cheers,

Is the dimension pretty large? Are there any subset updates within the sheet? I did hope for something a bit more clear from top, but not suprised.

Its around 5k elements and the spreadsheets are pretty vanilla, no VBA or anything funky going on. I've not been able to reproduce myself when using them either..

It appears to be happening randomly across the user base which is why were struggling to trace it....

Cheers

Could it be something to do with security?

Following on from Jim's security idea, not one I've seen cause issues but certainly something that could appear "random"... data spreading at a high level?

HI,

Thanks, the users do not have write access so I don't believe it can be that.

We did catch one user yesterday and they were creating private subsets in the pack for returning custom consolidations in an Excel pack, we've not established if it was creating subsets or referring to them in the pack that triggered the lock or this at all. They had taken a lock on the cube rather than the dimension which I don't understand at all though.

There also seems to be a pattern of users saying that they are just logging off and I'm wondering if this triggers a write-back to something, this would have to mean that PI is breaking and the message in top is wrong as well.

Cheers,

If users are logging off and they have cube viewer or subset editor open and they have changed anything then to the server this is a new unregistered private view/subset which is an object that has to be destroyed when the user logs off. This can cause a lock for sure but I thought that in 10.1 and 10.2 they had sorted this and view create/destroy shouldn't take out a lock.

Thanks lotsaram, if it is still running like that then I think this may be what is happening. Doesn't sound like it is something we do much about, except make the cubes run as fast as possible so the queues are short.
Cheers,

Logging off definitely still has the potential to cause locks in vanilla 10.1.1.

Sod's law says it will always be just after someone's kicked off a long running process that would otherwise run perfectly happily without causing locks.

Thanks for the confirmation Andy, the harder we look at things the more it seems like a proper problem with TM1. In a system with 200 plus concurrent read only users someone is always either running a fairly large report or logging off.

If someone is a read-only user they should be exactly that with no chance of taking a lock ever. It is very frustrating to have this kind of issue that you cannot design away.
Cheers,
Steve

It transpires that there is a fix for this in 10.1.1 FP1 but....you need to activate it in the cfg with a parameter

KeepPrivateSubsetsLoaded=T

Comes with caveat around RAM increase from keeping the private subsets loaded.
Its not dynamic.
Appears to resolve our test case.
Happy days!