16.10 - Deadlock Detection - Teradata Unity

Teradata Unity User Guide

Product
Teradata Unity
Release Number
16.10
Published
January 2018
Language
English (United States)
Last Update
2018-03-29
dita:mapPath
anz1496162519675.ditamap
dita:ditavalPath
ft:empty

A deadlock happens when two or more transactions are waiting for each other to give up locks. Three different types of deadlocks can occur with Unity.

Deadlocks within Unity-Managed Sessions
Unity performs deadlock detection for all managed sessions (sessions associated with managed routing rules). Since Unity does its own locking for all requests of managed sessions, deadlocks are detected before they have a chance to happen on the underlying managed systems. Unity resolves the deadlock at the time of detection.
Deadlocks on Underlying Unity-Managed Systems
With passive sessions, it is possible to have deadlocks at the database. Because passive sessions bypass Unity's standard locking and deadlock detection and are sent straight to the system (through the dispatcher process), deadlocks can occur at the Teradata system. Once Teradata detects a deadlock, it automatically takes appropriate action to resolve the deadlock.
Deadlocks Between Teradata and Unity
With Unity's passive routing, it is possible there are no deadlocks on the managed server or within Unity independently, but the system as a whole is deadlocked. Unity periodically obtains blocking locks information from the underlying systems, using the Teradata PMPC API. This lock information is combined with Unity's own lock information to detect deadlocks. If a deadlock is found, Unity or the Teradata server takes action to resolve the deadlock.