customer updates getting recorded in wrong update set

[Jay Gamblin]

Has anyone ever experienced this happening? We first noticed it when our system account that runs a scheduled import was recording the update that happens to the data source (Last run datetime) in random update sets.  I expect it to get recorded but since the system account has the default update set selected I expect it to get recorded there.  After a while we realized that some developers changes are also getting recorded in a different update set than is selected for their current update set.  Mostly happens on data sources and form changes but its quite random.  

Any ideas?

[Brian O_Donnell]

Jakarta Patch 4

We've even seen updates that were part of a scoped app that wound up in an update set in the global namespace. I did capture some information about a new one that happened this morning so I will be opening a case soon since I have something to actually share with them now.

What version are you on?

[Jay Gamblin]

We are on JP3a HF2.

We are also seeing updates in the global scope wind up in scoped applications. 

[Jay Gamblin]

Brian,

Just thought I would share that SN may have found a clue.  Here is the latest reply.

SN: I am making some progress in my investigation. I believe it is caused by changing the session's update set from any one of the 8 scheduler threads. These threads are used by scheduled jobs, async business rules, etc. Changing the update set for the session, using something like gs.putProperty() or via another method will cause subsequent processes run on that thread to be in the same update set. This means that updates created by async business rules would also appear in those update sets. If that session's update set is then completed and/or re-opened, it then causes that thread to bounce around between update sets similarly to what we are seeing in your instance. I am currently trying to find code similar to this in your instance.

[Brian O_Donnell]

After more investigation, we do not have any conclusive results. It has not happened for some time now, so we do not have anything to review at this point. We closed our incident with hi since we cannot reproduce.

[denisetaylor68 · Accepted solution]

This is a known problem in Jakarta PRB1263160, fixed in Jakarta patch 10, Kingston patch 7, and London releases.  It has caused us massive problems and update set cleanup in multiple environments.  Ours was caused by async business rules in scoped applications, causing duplicate update set artifacts to be deposited in other scoped update sets as well as global update sets...totally random.

If a session property is changed on a scheduler thread, such as through a script in an async business rule or a scheduled script execution, this session property will be set indefinitely on that scheduler thread's session until it is changed again or the node is restarted.
This means that every job or operation that runs through that thread will inherit its session properties. For example, if the sys_update_set property is set, all future updates generated on that thread will be recorded in the update set referenced by the property. This can result in updates appearing in seemingly random update sets from scheduled jobs, async business rules, etc.