What does "usp_conflict" in the messages in the stdlog.x files mean?

Document ID : KB000048411
Last Modified Date : 14/02/2018
Show Technical Document Details

Description:

Within the Service Desk Manager stdlog, there are may be frequent messages regarding "usp_conflict" or "usp_conflict_chg" and references to "refreshing cache" or "update_complete" in the SDM \log\stdlogs. For example, you may see messages that contain one of the following:

  • refreshing cache for table 'usp_conflict' rows ALL

  • refreshing cache for table 'usp_conflict_chg' rows ALL

  • Message external_update_complete received for usp_conflict (producer chgcnf)

  • Message external_update_complete received for usp_conflict_chg (producer chgcnf_chg)

If you're an SDM Administrator, you may be wondering:

  • Why are these messages so frequent?

  • What causes them to be written?

  • Why are they written?

  • Do I need to do anything about them?

Solution:

Overview of Message Impact

  • These messages are typically harmless.

  • They record that a "mass update" has occurred to the system.

  • They do not indicate a fault.

  • The "Edit in List" feature can trigger them.

Example of Messages

Here is a typical example of log entries written. Note these factors:

  • May cover either of the two tables usp_conflict or usp_conflict_chg.

  • Writes at "SIGNIFICANT" level and thus appears in SDM stdlogs at default log setting.

  • Occurs across many processes: bpvirtdb_srvr, ehwriter and every domsrvr eg domsrvr, domsrvr:01, domsrvr:wsp etc.

  • Occurs in a chunk.

  • On some systems, may occur frequently.

     10/03 10:45:40.08 MY_SERVER bpvirtdb_srvr 7388 SIGNIFICANT vdbsql.c 1414 refreshing cache for table 'usp_conflict' rows ALL        10/03 10:45:40.08 MY_SERVER ehwriter 9788 SIGNIFICANT vdbsql.c 1414 refreshing cache for table 'usp_conflict' rows ALL  10/03 10:45:40.08 MY_SERVER domsrvr:sa 11092 SIGNIFICANT factory.c 4970 Message external_update_complete received for usp_conflict (producer chgcnf) 10/03 10:45:40.08 MY_SERVER domsrvr 9268 SIGNIFICANT factory.c 4970 Message external_update_complete received for usp_conflict (producer chgcnf) 10/03 10:45:40.08 MY_SERVER domsrvr:01 4852 SIGNIFICANT factory.c 4970 Message external_update_complete received for usp_conflict (producer chgcnf) 10/03 10:45:40.08 MY_SERVER domsrvr:wsp 3140 SIGNIFICANT factory.c 4970 Message external_update_complete received for usp_conflict (producer chgcnf) 10/03 10:45:40.10 MY_SERVER bpvirtdb_srvr 7388 SIGNIFICANT vdbsql.c 1414 refreshing cache for table 'usp_conflict_chg' rows ALL 10/03 10:45:40.10 MY_SERVER ehwriter 9788 SIGNIFICANT vdbsql.c 1414 refreshing cache for table 'usp_conflict_chg' rows ALL 10/03 10:45:40.10 MY_SERVER domsrvr:sa 11092 SIGNIFICANT factory.c 4970 Message external_update_complete received for usp_conflict_chg (producer 	hgcnf_chg) 10/03 10:45:40.10 MY_SERVER domsrvr 9268 SIGNIFICANT factory.c 4970 Message external_update_complete received for usp_conflict_chg (producer chgcnf_chg) 10/03 10:45:40.10 MY_SERVER domsrvr:01 4852 SIGNIFICANT factory.c 4970 Message external_update_complete received for usp_conflict_chg (producer chgcnf_chg) 10/03 10:45:40.10 MY_SERVER domsrvr:wsp 3140 SIGNIFICANT factory.c 4970 Message external_update_complete received for usp_conflict_chg (producer 	chgcnf_chg)

It may draw the eye to the log entries if it writes frequently and to many processes. On large systems with many domsrvrs, the above chunk can be quite large.

If you were to put on a SQL Profiler Trace, you may see entries in time like so:

  • exec sp_executesql N'DELETE FROM usp_conflict WHERE usp_conflict.source_change = @P1 OR usp_conflict.conflict_change = @P2',N'@P1 int,@P2 int',<<Number>>,,<<Number>>
  • exec sp_executesql N'DELETE FROM usp_conflict_chg WHERE usp_conflict_chg.change = @P1 OR usp_conflict_chg.conflict_change = @P2',N'@P1 int,@P2 int',,<<Number>>,,<<Number>>
  • exec sp_executesql N'SELECT DISTINCT chg.open_date, chg.sched_start_date, chg.sched_end_date, chg.id, chg.risk, chg.chg_ref_num, chg.id FROM chg, usp_conflict, usp_conflict_chg WHERE ( chg.assignee = @P1 AND usp_conflict_chg.change = chg.id AND usp_conflict_chg.conflict = usp_conflict.id AND usp_conflict.is_resolved = 0 AND usp_conflict_chg.change = chg.id AND usp_conflict_chg.conflict = usp_conflict.id AND usp_conflict.del = 0) AND ( chg.tenant IS NULL OR chg.tenant IN (SELECT ca_tenant_group_member.tenant_id FROM ca_tenant_group_member WHERE ca_tenant_group_member.tenant_group = @P2) ) ORDER BY chg.open_date DESC',N'@P1 varbinary(16),@P2 varbinary(16)',<<Number>>

Where the first two correspond to the cache refresh and the latter to the "update_complete." These are examples only - the content of these messages will vary depending on the nature of the update being done.

Frequency of Messages

These messages are not seen in the same frequency on all SDM systems. Some sites will be very familiar with these entries in the SDM , while others will rarely see them.

A site prone to these messages may see around 2,000 writes to the stdlogs each day (or more), and still be considered to be operating normally.

An example from a real site is every minute during peak times, every 5 - 10 minutes during business hours, and every four hours during off-peak.

A quick profile of such a site may be:

* High volume of updates.
* Large number of users.
* Many data integration points. Eg pdm_load, Web Services, bop_cmd.

Cause of Messages

These messages are caused by any "mass update" to the Service Desk Manager "domsrvr."

There are two typical database update paths in Service Desk Manager.

  1. Single update.

    The first is typified by doing an edit to a single Incident via the web client "Edit" feature.
    Information to update is entered by the user, the domsrvr then works directly with its cache.
    There is no need to refresh the cache, because the cache is already in memory and the changes may be done directly.
    No message is written to the stdlog as this is a typical activity.

  2. Mass update.

    This encompasses all multiple writes to the database.
    Service Desk Manager has a large number of integration point:

    * Many CA products
    * Web Services
    * Bop_cmd, AHD.dll
    * GRloader, pdm_load
    etc

Rather than having a separate update routine for each, a single "mass update" routine is maintained.
This is for simplicity and quality of code maintenance in this important area.

The mass update code bypasses the domsrvr during the mass update. It therefore needs to notify the domsrvr of the update, so that domsrvr can update its cache.
The mass update writes a "SIGNIFICANT" message to the SDM stdlog to record this.
These messages can prove very useful in correlating to performance issues, among other things.

This does lead to an unexpected use case:

* The SDM web client 'Edit in List' feature also uses the "mass update" code.

This is because multiple records may be updated at once - it is the main purpose of this feature.

So on sites where there are a large number of users, and their business process flow involves using the "Edit in List" feature, you may see a large case of the above messages.

Can the Messages be Suppressed?

No. Nor would it be entirely desirable to do so.

Changing the writing of these message would mean either writing a special subcase for the "mass update" routine, or would require extra overhead within the current mass update routine to determine source of update. The latter would add extra overhead to every update, the former causes a split in the code line which is desirable to avoid.

The messages themselves do contain significant information:

* Domsrvr bypass
* Mass update
* Cache refresh

any of which can be useful diagnostically.

Further, these messages have proven themselves useful in actual performance issues, where the messages pointed to a performance problem.
The messages led to a performance problem with the Edit in List and the code was optimised to resolve this.

In short, the messages are staying, barring strong user support for an "Idea" in the CA Technologies, SDM Global Community.

Does anything need to be done regarding these messages?

Typically no, for reasons above. These messages are informational only. There is no overhead associated with their writing.

However, if you have performance issues, then working back from the performance problem may make use of these messages.