This discussion is archived
2 Replies Latest reply: Nov 8, 2012 9:30 PM by 856103 RSS

LOCK_GRANTS_IMMED,LOCK_GRANTS_WAIT and XACT_D_COMMITS in TimesTen

856103 Newbie
Currently Being Moderated
Hi,

On running the following query, I can see that values of LOCK_GRANTS_IMMED,LOCK_GRANTS_WAIT and XACT_D_COMMITS increase over a 10 min interval.

select LOCK_GRANTS_IMMED,LOCK_GRANTS_WAIT,XACT_D_COMMITS from sys.monitor;

362428, 170, 2751
588110, 275, 2925
717729, 322, 3033
1092545, 454, 3324
1244723, 541, 3450

I read in TimesTen Documentation :

The LOCK_GRANTS_IMMED, LOCK_GRANTS_WAIT columns in the SYS.MONITOR table provide some information on lock contention:
■ LOCK_GRANTS_IMMED counts how often a lock was available and was immediately granted at lock request time.
■ LOCK_GRANTS_WAIT counts how often a lock request was granted after the requestor had to wait for the lock to become available.

Does the increase represent a direct impact on my application performance ? How can i minimize the same ??

When i checked XACT_ROLLBACKS,DEADLOCKS,LOCK_TIMEOUTS,CMD_PREPARES,CMD_REPREPARES, CMD_TEMP_INDEXES,LOG_BUFFER_WAITS,LOG_FS_READ from from sys.monitor, all values were near zero and not increasing.

Kindly assist.

Regards,
Karan
  • 1. Re: LOCK_GRANTS_IMMED,LOCK_GRANTS_WAIT and XACT_D_COMMITS in TimesTen
    ChrisJenkins Guru
    Currently Being Moderated
    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.

    Chris
  • 2. Re: LOCK_GRANTS_IMMED,LOCK_GRANTS_WAIT and XACT_D_COMMITS in TimesTen
    856103 Newbie
    Currently Being Moderated
    Thanks Chris... You're a big help (as always....)

Legend

  • Correct Answers - 10 points
  • Helpful Answers - 5 points