Resolution:
Description:
============
A deadlock occurs when two or more transactions block each other while waiting on the other one to free an object they both need to finish their processing.

With KIS based products as TIBCO KTP or TIBCO KPSA, when a deadlock is detected, one of the transactions is automatically aborted and retried allowing the other one to complete successfully.

However, when this deadlock involves an external transactional environment as a database system, the deadlock situation can not be detected.

Environnement/Product version:
===========
Solaris / Linux

Symptoms:
========
Several transactions blocked forever (or until the database connection is dropped), sharing the same KTP/KPSA objects and database rows.

Cause:
=====
The undetected deadlock is the result of mixing KTP/KPSA locks with database locks in two or more concurent transactions that result on a deadlock situation.

Here is an example of what can happen:

Note1: WL means here Write Lock.
Note2: Oracle lock mode (default): Row Exclusive Table Locks (RX)

Transaction1
| takes a WL on K_Obj
|
|              Transaction2
|     | takes a WL on DB_Row
|     | Needs a WL on K_Obj
     ?   Transaction2 waits for a lock on K_Obj, oracle transaction is pending.
|
? Transaction1 needs a WL on DB_Row, hangs forever until transaction 2 is committed in Oracle.

Resolution:
==========
If this case occurs a restart of the database listener or of the application is needed to solve the deadlock situation, but the same situation can reoccur.

This is a design issue that needs a code change to avoid this scenario by serializing any concurrent transactions that would work on the same KTP/KPSA and database objects.

KTP/KPSA – Database : undetectable deadlock