- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
03-14-2018 09:04 AM
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?
Solved! Go to Solution.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
09-11-2018 10:10 PM
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
09-17-2018 07:33 AM
We had a business rule which called GlideUpdateSet.set() in an asynchronous context. Async business rules run on the system scheduler threads, which have their own unique sessions, and this API method changes the update set for those sessions. These sessions persist on the threads across tasks, and would typically only be reset by a node restart. For this reason, the thread this business rule runs on will be "stuck" in that update set indefinitely until either the update set is completed, or the session property is changed again
