tm1 elementSecurityPut cube locking

[dan.kelleher]

Does anyone know if using an elementsecurityput as opposed to a cellputs causes cube locking?

We are seeing thread queuing in TM1Top and believe this is the cause (we have no other metadata changes in the processes).

Thanks,

Dan

[tomok]

I don't know for a fact that it does any "locking" but I am pretty sure it does something like that because CellPutS and ElementSecruityPut are not the same thing. CellPutS is merely writing a string value to a cube. ElementSecurityPut is writing a string value to a cube PLUS telling TM1 to refresh security. I imagine that second part has some serious overhead that clients are going to have to wait for.

[Vel]

Why the Lock is creating ?

[qml]

If you think about it, it makes perfect sense to create a lock on objects that have security applied to them for the duration of the full or partial security refresh. If it were possible to, say, change element security in the middle of someone refreshing a report then they could get a report that would be partly based on the old security and partly on the new security. To avoid this TM1 prevents objects whose security you are trying to amend from being accessed during the partial security refresh that is being kicked off by ElementSecurityPut() and probably even for the full duration of the process that executes this function.