TM1 Locking Post 9.5.2

[jyoung66]

Hi

Can anyone explain the nature of TM1 IX locking post 9.5.2? I have not had any joy looking in the literature

I note that from IBM Cognos TM1 The Official guide that "The IX lock is when you intend to modify an object. However if a transaction holds an IX lock, it is allowed to modify the object. Only one transaction at a time is allowed to have an IX lock on the object. For instance and IX lock is aquired on a dimension ...if an element is inserted or removed"

From this I would have assumed that, post parrallel interaction, IX locks are metadata specific.

However I note that when I run TI processes with no metadata changes, just cube loading for instance, the IX<> in TM1 top has a value; i.e. IX<14>

What is going on here? what is IX<14> telling me? As far as I am concerned, there should be nothing in non metadata processes that is "one transaction at a time"

[TableManagerOne]

When Top displays IX<N>, it indicates that N locks have been granted to that thread in IX mode. With PI enabled, these are likely for "metadata" changes, though the changes may be to internal objects TM1 maintains (for example, an unregistered copy of a view.) Another way to view these statistics would be the Windows Performance Monitor counters under "IBM Cognos TM1:Locks". I think that you'll find that even with PI enabled, plenty of locks are being acquired in IX mode. The important part is which objects correspond to those locks. If the object is private or unregistered, contention with other threads will probably be unlikely, and consequently, granting IX mode to a thread on that object's lock is effectively harmless. What you want to avoid in design is contention on "popular" public objects like a dimension or cube. Some best practices are detailed in "Best practice use of Parallel Interaction" of the documentation.

[TableManagerOne]

I suppose another way to answer your question would be, "not a whole lot." If you find that the IX locks being granted are causing contention (or you want to track them down before you reach production,) you'll likely need to resort to logging, which is not well documented (as pointed out in an adjacent thread...) The following logger settings may be useful:

Code: Select all

log4j.logger.TM1.API=DEBUG
log4j.logger.TM1.API.Parameters=INFO
log4j.logger.TM1.Commit=DEBUG
log4j.logger.TM1.Lock=DEBUG
log4j.logger.TM1.Lock.SYSMT=INFO
log4j.logger.TM1.Lock.CriticalSection=INFO

You can add to these as you hone in on the locks in your specific scenario.

[jyoung66]

Excellent answer.

I asked that same question to many of the "gurus" that I knew and stumped them all.

I will be back here from now on.

Thank you very much.