TAFJ Database Lock Manager
This section explains the concept of TAFJ Database lock manager and the working of its two algorithms.
You need to edit the [project].properties file to enable the DATABASE lock manager as shown below.
temn.tafj.locking.mode = DATABASE
The Database locking mode has two different algorithms:
- Mode 1: It uses the TAFJ_NONEXISTING_ROWS table.
- Mode 2: It uses the TAFJ HASHLOCKS table..
The default mode of Database lock manager is Mode 1 but you can switch the mode to Mode 2 by adding the below property in the properties file.
temn.tafj.jdbc.db.locking.insert.rows.on.demand = false
You need to execute the savepoint stored procedure inside the database from TAFJ_HOME/dbscripts/<DB flavour>/createSavePointStoredProc.sql for Temenos Transact service architecture support.
Mode 1
This mode makes use of an internal technical number table TAFJ_NONEXISTING_ROWS for handling the locks of non-existing records from the application. This table is created on fly in the runtime environment when the locking mode is set appropriately.
This mode handles the inserts and deletes in a technical table TAFJ_NONEXISTING_ROWS. This is performed on demand as a part of transaction boundary.
In cases when JVM aborts, you can use the clean up mechanism for application server. Here, you need to execute the CLEANUP.STALE.ENTRIES JBC routine, which is shipped with TAFJ in TAFJBasic.jar.
Example
Run the command below from TAFJ_HOME/bin:
tRun CLEANUP.STALE.ENTRIES
Before executing the cleanup routine:
sql> SELECT * FROM TAFJ_NONEXISTING_ROWS; RECID | CREATEDTIME FBNK_CURRENCY*YYY | 2019-11-11 15:53:58.64 FBNK_CURRENCY*YZY | 2019-11-11 15:54:07.634 FBNK_CURRENCY*GGG | 2019-11-11 15:54:12.037 FBNK_CURRENCY*UUU | 2019-11-11 15:54:16.015
After executing the cleanup routine:
[ERROR] 2019-11-11 16:05:13,803 [CLEANUP_STALE_ENTRIES_723715090] BASIC {command=CLEANUP_STALE_ENTRIES, sessionId=723715090} - DATE : 18943 > 18943 or TIME : 675 > 600 for the entry : FBNK_CURRENCY*YYY
[ERROR] 2019-11-11 16:05:13,806 [CLEANUP_STALE_ENTRIES_723715090] BASIC {command=CLEANUP_STALE_ENTRIES, sessionId=723715090} - Deleting : FBNK_CURRENCY*YYY
[ERROR] 2019-11-11 16:05:13,845 [CLEANUP_STALE_ENTRIES_723715090] BASIC {command=CLEANUP_STALE_ENTRIES, sessionId=723715090} - DATE : 18943 > 18943 or TIME : 666 > 600 for the entry : FBNK_CURRENCY*YZY
[ERROR] 2019-11-11 16:05:13,846 [CLEANUP_STALE_ENTRIES_723715090] BASIC {command=CLEANUP_STALE_ENTRIES, sessionId=723715090} - Deleting : FBNK_CURRENCY*YZY
[ERROR] 2019-11-11 16:05:13,884 [CLEANUP_STALE_ENTRIES_723715090] BASIC {command=CLEANUP_STALE_ENTRIES, sessionId=723715090} - DATE : 18943 > 18943 or TIME : 661 > 600 for the entry : FBNK_CURRENCY*GGG
[ERROR] 2019-11-11 16:05:13,886 [CLEANUP_STALE_ENTRIES_723715090] BASIC {command=CLEANUP_STALE_ENTRIES, sessionId=723715090} - Deleting : FBNK_CURRENCY*GGG
[ERROR] 2019-11-11 16:05:13,924 [CLEANUP_STALE_ENTRIES_723715090] BASIC {command=CLEANUP_STALE_ENTRIES, sessionId=723715090} - DATE : 18943 > 18943 or TIME : 657 > 600 for the entry : FBNK_CURRENCY*UUU
[ERROR] 2019-11-11 16:05:13,926 [CLEANUP_STALE_ENTRIES_723715090] BASIC {command=CLEANUP_STALE_ENTRIES, sessionId=723715090} - Deleting : FBNK_CURRENCY*UUU
Mode 2
This mode makes use of an internal technical number table TAFJ_HASHLOCKS containing values ranging from 0 – 2147483647 (maximum integer value).
You can populate this table by running the TAFJ_HOME/dbscripts/<DB flavour>/tafj_hashlock_tab_prepare.sql script. The procedure runs for around 1 to 2 hours depending on the hardware of the database server.
For oracle database, the procedure needs to run in SYSDBA login as it involves creation of index, primary key, altering user data files and altering temp table spaces to accommodate the huge table inside the database.
Behind the scenes (in runtime)
TAFJ can take locks by using the underlying database locks. For READU and other locking commands where records exists, the lock manager will issue a SELECT FOR UPDATE (either blocking or non-blocking depending on the READU clause also has a LOCKED clause) to the database to lock the record before an anticipated write. This means that a JBC statement RELEASE will have no effect until a commit or rollback is performed. Temenos Transact is wrapped inside transactional boundaries where the RELEASE statement is ignored until the transactional boundary ends. Any L2 or L3 code must confirm to the same to use DATABASE locking mode.
When a lock on a non-existent row is requested from Temenos Transact application the TABLENAME*RECID is hashed to an integer value and a lock is obtained on the TAFJ_HASHLOCKS table.
READU without LOCKED Clause for a Non-Existent Record
In the screen below, you can see the second session is waiting on lock for the first one to commit or roll back.
Once the rollback from first session, the other session grabs the lock.
READU with LOCKED Clause for a Non-Existent Record
When both the sessions ask for a READU and LOCKED clause on a non-existent record, the first one acquiring the lock will end up in ELSE clause and the second thread enters LOCKED clause and continues.
Reporting locks with DBTools (with the LOCKS command) will appear a bit different when using this mode. When you issue the LOCKS command, only the blocking locks can be viewed under this mode.
Session A takes a lock on FBNK.CURRENCY CHF without a LOCKED clause and session B does the same. The session B hangs till it manages to obtain the lock to continue further. In this case, an entry in LOCKS command will show up as blocking lock along with the time in seconds is blocked.
In this topic