DB2 thread
The connection between an application and DB2 for the length of its work, which DB2 tracks and can display.
Also written thread, DBAT, allied thread, -DISPLAY THREAD, DB2CONN
When a program uses DB2, DB2 creates a thread for it: a connection that carries the program's identity, its package and its locks for the length of its work. The thread is how DB2 knows who is doing what.
There are two main kinds. Allied threads are for work on the same z/OS system: batch jobs, TSO users, CICS and IMS transactions. Database access threads, called DBATs, are for remote work arriving through DDF. CICS keeps a pool of threads, defined with DB2CONN and DB2ENTRY resources, so transactions do not have to create a new one every time.
The command -DISPLAY THREAD shows active threads: who owns them, what they are running and whether they are waiting. DBAs use it daily, especially when something is stuck.
A thread that runs for a long time without committing keeps its locks, and other work may wait for it or time out. In a problem, "find the thread holding the lock" is often the first step, then deciding whether to wait for it or cancel it.
Where can I learn this hands-on?
Right here, at ZedBank. You take a junior job at a simulated bank and learn each part of the work by doing it, with Zed beside you. There's nothing to install.
Start at ZedBankRelated
- DB2 for z/OSIBM's relational database on the mainframe, where a great deal of the world's banking and insurance data is stored.
- DRDADistributed Relational Database Architecture: the standard way applications on other computers connect to DB2 for z/OS over the network.
- CICS regionOne running copy of CICS, with its own programs, files and users. A site typically runs several.
- Commit and rollbackMaking a set of changes permanent together, or undoing them together, so a transaction never half-happens.
- DeadlockWhen two programs each wait for data the other has locked, so neither can continue; DB2 cancels one of them.