This content has been marked as final. Show 2 replies
LOCK_GRANTS_IMMED is a normal consequence of almost all processing. It will usually be a large value increasing rapidly. There is nothing you can do about that and it is not a cause for concern.
The same is largely true for LOCK_GRANTS_WAIT with the caveat that one does not know how long the 'wait' was, only that it was non-zero and less than the defined LockWait timeout 9which by default is 10 seconds). In general if LOCK_GRANTS_WAIT is a small fraction of LOCK_GRANTS_IMMED then this is usually considered okay.
Generally, as long as LOCK_TIMEOUTS and DEADLOCKS are zero or very low and not increasing then you do not have a concurrency issue relating to locking.
XACT_D_COMMITS represents the number of durable commits across the entire datastore. A durable (synchronous to disk) commit is much slower / more expensive than a non-durable (async to disk) commit so if your actual application is performing durable commits then this will have a marked impact. Then again in that case you are probably doing durabel commits because you need the protection they provide so you may not have any choice. Note however that there are other components within TimesTen that also perform durable commits; checkpointing, replication agent and cache agent. The durable commits that they perform are not within the context of an application transaction and so do not have any performance impact on your application.
Hope that helps.