A temporary table contains specific data for a particular transaction or SQL session and is not available to be accessed by other users. In general, therefore, HiRDB does not acquire locks for table operations other than when a temporary table is instantiated. This subsection explains locking for temporary tables.
When a temporary table is instantiated, HiRDB acquires the locks shown in the following table.
Table 12-30 Locks acquired when a temporary table is instantiated
Resource type name | Description | Unlock timing | |
---|---|---|---|
Transaction-specific temporary table | SQL session-specific temporary table | ||
RDAR | RDAREA (table and index#1 storage RDAREA) | When the transaction is completed | When the DISCONNECT statement is completed |
TABL | Table | ||
RATM | User directory table information | ||
RAIM | User directory index information#1 | ||
SBMB | User directory segment information | ||
TEMP | Temporary table instantiation control information | After the temporary table has been instantiated#2 | |
TPID | User-specific ID management (temporary table) | When the DISCONNECT statement is completed | |
RDAS | RDAREA status management | After the temporary table has been instantiated#2 | |
RRAM, TRAL, TRAI | RDAREA management information | ||
PTBL | Table for preprocessing | When the DISCONNECT statement is completed |
When the following SQL statements are executed, a lock is acquired only for the preprocessing table (PTBL):
Note that executing the following SQL statements on a temporary table will not lock pages, rows, or key values:
If you are performing an operation on a temporary table and, at the same time, you execute any of the following operations, a lock-release wait status or an execution error might result: