J2EE - Information - How to troubleshoot Transaction Status variation issues for same source between snapshots

Purpose

This page explains about the method to troubleshoot Transaction Addition/Modification/Deletion  issues for same source between snapshot

Applicable in CAST Version
Release
Yes/No
8.3.x(tick)
Details

Transactions status modification issues for unchanged source code are handled in the TKB guides under Transaction Configuration Center - Enhancement - Transactional Functions - Status Variation. Regardless of if the status whether it is is ADDED, DELETED or MODIFIED the general idea of the guides is to

  1. Identify any reasons that are due to configuration changes or entry point changes
  2. Check if the compute type has changed between snapshots (AEP or EFP)
  3. Identify the objects taking part in transaction in current and previous snapshots
  4. Check if object status and/or links between objects taking part in transaction has changed

Assuming a mature environment where snapshots are taken on a rate of 4/6 times per year, huge transaction status modification may be due to instabilities in links, which is the third point in the action plan. Changes in links between the snapshots can be identified (in addition to above TKB) with

  1. Below query helps you to identify the missing link or added links for a particular transaction which can be the root cause for DELETED or MODIFIED transaction issues with unchanged objects.
    This query will compare current and previous KB to find the difference in links.
  2. NOTE: BOTH KBs SHOULD BE IN SAME SERVER TO GET THE DIFFERENCE
    select distinct L.link_id, L.caller_id, L.called_id, typclr.typdsc, typcle.typdsc
    FROM
    l8328_30449_vam_prev.DSSAPP_TransactionView T2
    JOIN
    l8328_30449_vam_prev.CTV_links L
    ON T2.Child_ID = L.caller_id
    JOIN
    l8328_30449_vam_prev.DSSAPP_TransactionView T1
    on T1.Child_ID = L.caller_id and T1.Object_ID = T2.Object_ID
    JOIN
    l8328_30449_vam_prev.DSS_Transaction TR
    on TR.object_id = T1.object_id
    AND T1.object_ID = <Modified_Transaction_ID>
    AND link_id not in (select link_id from l8328_30449_vam_cur.CTV_links)
    join l8328_30449_vam_prev.keys k1
    on k1.idkey = L.caller_id
    join l8328_30449_vam_prev.keys k2
    on k2.idkey = L.called_id
    join l8328_30449_vam_prev.typ typclr
    on typclr.idtyp = k1.objtyp
    join l8328_30449_vam_prev.typ typcle
    on typcle.idtyp = k2.objtyp
    Where L.link_id
    not in
    (
    select prev_acc.link_id
    from
    (
    select *
    from l8328_30449_vam_cur.ctv_links
    where caller_id in (
    
    select L.caller_id
    FROM
    l8328_30449_vam_prev.DSSAPP_TransactionView T2
    JOIN
    l8328_30449_vam_prev.ctv_links L
    ON T2.Child_ID = L.caller_id
    JOIN
    l8328_30449_vam_prev.DSSAPP_TransactionView T1
    on T1.Child_ID = L.caller_id and T1.Object_ID = T2.Object_ID
    JOIN
    l8328_30449_vam_prev.DSS_Transaction TR
    on TR.object_id = T1.object_id
    AND T1.object_ID = <Modified_Transaction_ID>
    AND link_id not in (select link_id from l8328_30449_vam_cur.CTV_links)
    )
    and called_id in (
    select L.called_id
    FROM
    l8328_30449_vam_prev.DSSAPP_TransactionView T2
    JOIN
    l8328_30449_vam_prev.ctv_links L
    ON T2.Child_ID = L.caller_id
    JOIN
    l8328_30449_vam_prev.DSSAPP_TransactionView T1
    on T1.Child_ID = L.caller_id and T1.Object_ID = T2.Object_ID
    JOIN
    l8328_30449_vam_prev.DSS_Transaction TR
    on TR.object_id = T1.object_id
    AND T1.object_ID = <Modified_Transaction_ID>
    AND link_id not in (select link_id from l8328_30449_vam_cur.CTV_links)
    )
    
    ) Links_ADDED
    join l8328_30449_vam_prev.CTV_links prev_acc
    on Links_ADDED.caller_id = prev_acc.caller_id
    and Links_ADDED.called_id = prev_acc.called_id
    )
  3. For example if, in current run transaction is deleted but objects are unchanged then this might be due to missing link issue. So in this case you can replace current schema name in below query within NOT IN blocks. Rest all the place will have previous schema name. This will result in all the missing link details with link_id/caller_id/callee_id/object_type details.
  4. For the case of modified transaction main cause will be due to added links so you can place the previous schema name in NOT IN blocks of below query and rest all place will have previous schema name.


Once you have identified the missing links, you will have to follow the CMS Snapshot Analysis - Run Analyzer - Missing or Wrong links between two objects TKB which will may lead to reevaluate issue as a CMS Snapshot Analysis - Run Analyzer - Missing objects issue

For JEE analyzer more specifically if the same version of the analyzer is used between snapshots there are some specific points to focus on the missing link page:

  1. Links created by Inference engine: the links created by Inference Engine can be identified in the backend by the link properties in Enlighten and can be unstable between runs. Solution here is to increase the procedure call Depth parameter in IIE parameters to 5000. the impact of this change is to have LESS and more accurate links. It should be applied to the snapshot that has more incorrect de-virtualization links created
  2. Links created by resolving method arguments. This is the first step described in CMS Snapshot Analysis - Run Analyzer - Missing or Wrong Links per technology - J2EE. When a method parameter is not resolved by the analyzer then this can lead to a missing links. The action plan when the links are missing/added between snapshots is:
    1. Check the arguments of the snapshot where the link is missing in Enlighten. If a parameter is not resolved then it will not be underlined in Enlighten and it will create a warning of type CMS Snapshot Analysis - Run Analyzer - Warnings - JEE with extension - JEE Analyzer - JAVA124: Cannot resolve 'XXX' as type
    2. Since the method parameter has been resolved in 1 of the snapshots apart from the mentioned troubleshooting guide we have an additional information: we can verify in the analysis log(of the run where the link is created) which .jar includes the .class that resolved the argument.
    3. Following guide CMS Snapshot Analysis - Run Analyzer - Warnings - JEE with extension - JEE Analyzer - JAVA124: Cannot resolve 'XXX' as typestep 3 describes how to locate the .jar file in source. But this may not be needed since we have the additional info: we know the .jar that was used to resolve the argument
    4. As a WA adding the .jar in the application classpath can solve the issue. Additional steps are described in the guide to deepen the investigation if needed on DMT level, since .jars in many scenarios are fetched automatically from source code repositories.
Notes/comments