Long term and transactional locks
The native KDB database can lock a row at any time, even outside a transaction. However other SQL databases, such as Oracle, can only lock within a transaction. KDB can work around this limitation by using two strategies:
Implied transactions
It will start an implied transaction if the program attempts to lock a row outside a transaction using the _KDB_LOCK transactional lock type. This is called an implied transaction which will last until the exact same row is updated or deleted in which case the implied transaction is committed. If the row is unlocked with KI_UNLOCK then the implied transaction is rolled back. If an explicit WHILE TRANS transaction is later started then the implied transaction is subsumed into the explicit one and the commit for both takes place at the END TRANS.
Optimistic transactions
Optimistic transactions are enabled with a connection attribute. KCML will then start a transaction on any statement that needs one and will stay in the transaction until an event like form input occurs whereupon it will commit. Any outstanding locks at the point of the commit will be converted to long term locks. This can improve performance and permit locks to persist.
Long term locks
A program can nominate a lock as long term by using the _KDB_LOCK_EXT lock type when reading the row with functions like KI_READ_RANDOM. A long term lock is managed outside the database's transactional model by tracking the locks in a special database table. The row itself is also marked in a hidden column. KDB can detect and ignore a stale lock caused by a database crash or an application server crash. Long term locks owned by a handle are released when the handle is closed and so are automatically cleaned up on a CLEAR, $END or PANIC.
When taking a long term lock a special transaction is invoked lasting just for that function. It is an error to take a long term lock inside either an implied or an explicit transaction. Rewriting or deleting a long term locked row inside of a transaction will release the lock at the end of the transaction. A lock can also be released with KI_UNLOCK however this will rollback the implied transaction.
Compatibility
The native KDB database does not need implied transactions and so the concept is not relevant to these types of tables. Long term and transactional locks are implemented identically and both _KDB_LOCK and _KDB_LOCK_EXT have the same effect.
Long term locks and the lock type enumeration were introduced with KCML 6.60.
See also
Transactions in KCML