Hello,
I would like to discuss the performance of the Post operation in Utility Network when updates have been made in subnetworks.
Explanations :
I am in an 11.3 environment, editing a branch versioned feature service with Utility network. Default is protected and eventing is disabled on default (enabled on versions).
The standard workflow is to edit features in a version and, when needed, to update subnetworks. This will trigger some attribute rules in the version. Then to reconcile and post to default.
When editing features and posting, without updating subnetworks, the Post time is good. Example : move a vertex in a LV cable --> post in ~20 seconds
However, as long as I update the subnetwork, the post time increases greatly, often causing a client-side timeout after 10 minutes.
Same example with only 1 vertex moved, and LV subnet updated --> mode than 10 minutes for a total of 4 changes in the version
After that, the version seems to be locked until the server ends the Post operation. During this time, any operation will cause the error :
| SEVERE | 4 août 2025, 10:26:27 | StopServiceEditing failure (sessionID: {9C555C41-19C2-4E2C-B6BB-B3E9C2B78515}) (User session application lock in progress - operation not allowed) Session Application lock in progress [Session application lock in progress - operation not allowed] |
But if I wait enough time, I can get the version access back, then go back to Default and see the edits have been posted.
I don't understand what can cause such an increasing post time.
If anyone has information and solution...
Accepted Solutions
After some testing, I discovered that the geodatabase version was causing the problem.
The geodatabase was originally created with ArcGIS Pro 3.3.2. After upgrading to 3.3.4, the time to publish changes became more reasonable (between two seconds and a few minutes maximum, depending on the number of changes).
With the help of Robert Krisher, we identified at least two bugs that could be causing the problem:
After some testing, I discovered that the geodatabase version was causing the problem.
The geodatabase was originally created with ArcGIS Pro 3.3.2. After upgrading to 3.3.4, the time to publish changes became more reasonable (between two seconds and a few minutes maximum, depending on the number of changes).
With the help of Robert Krisher, we identified at least two bugs that could be causing the problem:
