Attribute Rules - A Deep Dive - DevSummit 2024
Because the services is reading and caching the definitions of the geodatabase it acquires the shared lock. This blocks anyone from going to the database and update the definition which will result in the service having stale/outdated definitions which can cause problems.
If you know that, hey I'm just changing an alias of a field or adding a comment to an attribute rule, yes it is updating the definition but it won't cause any harm, then yes it is safe to uncheck that option so the service won't acquire any locks. and Yes we refer to dedicated instances here because those cache the definitions. I'm not familiar very much with shared instances behavior but I would assume they destroy all cache after every request because you could open multiple workspaces on the same shared process and that will cause bloat in memory and perhaps bugs.
For the maxCacheAge, you can add only add it in the admin api, right under the properties of the mapserver of your service. I think if the default is 300 (5 minutes), is it not there by default. thanks for bringing up the issue that it isn't in the doc
For the feature dataset question I don't think we document that as its an implementation details so it won't be in the official doc, but perhaps mentioning it as part of best practices in general would be good idea.
If you enabled debug logging , you should see a debug entry, something like this. Which tells you how long the broadcast took, and how many tables/classes and relationships were touched. So if you have a feature dataset with 100 classes, and you just published one of those classes as a service, all 100 will be opened when you edit that class.
BeginBroadcastStopEditing;Broadcasting Stop editing accross: 1 Feature Datasets, 24 Tables, 17 Relationships
Hope that helps
