Folks,
Here's a really interesting problem I've noticed. After trying to apply some feature updates to one of my feature services, the operation will fail (due to an underlying DBMS error). The database itself won't contain the feature updates (since none were committed due to the error)... but the feature service will contain the updates.
This scenario is probably best described by describing each stage of interaction with the feature service and the DBMS. It's important to note that I do know the cause of the underlying DBMS error - I've written a faulty "FOR UPDATE" trigger on my feature class' "base" table in SQL Server 2008.
That being said, with the faulty trigger in place, here's how things go down:
1) An edit is made to one of the features. While I'm doing this via a Silverlight app, just think of it in terms of the "updateFeatures" REST operation. For the sake of this example, let's say the "NAME" attribute for the edited feature changed from "OLD HOUSE" to "NEW HOUSE".
2) The operation bombs, because the trigger code is faulty and cannot be executed.
3) Subsequent queries to access the feature via the Feature Service will claim, even though the update failed, that its NAME is "NEW HOUSE".
4) Inspection in ArcMap, however, proves that SDE really didn't modify the feature. SDE will report the feature as having a NAME value of "OLD HOUSE".
When this first happened, I became pretty befuddled. I tried clearing my browser cache, my REST cache, the whole bit. No luck. On a hunch, I began to wonder if the Feature Service might cache features itself, to avoid having to go back to the database when servicing queries. Maybe its internal cache state wasn't cleaned up when the feature update failed, and it incorrectly reflected what the state would be, had the update succeeded.
This lead me to try something else: simply restarting the service. That worked! Subsequent queries to the feature in this example return "OLD HOUSE", as they should ... since that's what is really in the database.
While I do plan on fixing my trigger, of course, the effect I've described makes me nervous. If a DBMS error like this can throw the Feature Service into a tailspin, that's not good - since I haven't a clue how to recover from it other than manually restarting the service.
Does anyone know if the Feature Service does, indeed, use some sort of internal cache? Maybe this effect is a bug and/or a known issue? Or, could there be something else going on that I haven't thought of?
Thanks for your time!
Brooks
