Hoe lang moet ik (cache) verwijzingen houden naar IWorkspace, ITable, IFeatureClass?

Na vele maanden van programmeren met ArcObjects, voel ik me nog steeds enigszins onzeker over twee gerelateerde problemen:

Voor sommige bewerkingen moeten werkruimten en gegevenssets expliciet worden geopend voordat ze kunnen worden gebruikt. (Werkruimten worden bijvoorbeeld geopend via IWorkspaceFactory.Open() , ITable s via IWorkspace.OpenTable() , etc.) Aan de andere kant Met de hand zijn er bewerkingen die kunnen worden uitgevoerd zonder eerst werkruimten of gegevensreeksen te hoeven openen (bijvoorbeeld geoprocessing of bewerkingen die IName s als invoer accepteren).

Thus I suspect that there is a certain cost involved with opening a workspace or dataset, which can only be avoided for the latter type of operations. And because of that, I tend to keep (cache) references to the opened IWorkspace, ITable, IFeatureClass, … instances whenever I open these for the first time.

Mijn eerste onzekerheid is of het in de cache plaatsen van IWorkspace , ITable , etc. referenties ooit voor problemen zou kunnen zorgen. Meer in het bijzonder zijn er ArcGIS-bewerkingen, b.v. op tabellen, die vereisen dat er geen live verwijzingen naar "open" tabellen zijn?

(Ik ben me op dit moment bewust van slechts één mogelijke probleembron: als een werkruimte of gegevensset wordt verwijderd, moeten alle verwijzingen in de cache ernaar worden weggegooid.)

Mijn tweede, gerelateerde onzekerheid betreft hoe lang ik werkruimte en verwijzingen naar datasets maximaal zou moeten cachen. Laten we zeggen dat ik een ArcGIS-extensie schrijf; zou het OK zijn om vereiste werkruimten te openen wanneer de extensie is geladen en alleen de referenties opnieuw in te stellen wanneer deze wordt leeggemaakt? Zou het zelfs goed zijn als ik hetzelfde deed voor datasets?

Links naar ESRI-referentiedocumentatie (of voorkennis) zijn van harte welkom.

5
Misschien wilt u het antwoord op deze vraag lezen gis.stackexchange.com/questions/15936/… om te begrijpen hoe een IName-object (bijv. IWorkspaceName) verschilt van hun gekoppelde tegenhanger (bijv. IWorkspace). Petr heeft het juiste antwoord, dus je hoeft het niet te herhalen :)
toegevoegd de auteur FlySwat, de bron

1 antwoord

U kunt een gegevensset (bijvoorbeeld een werkruimte, functie-gegevensset, featureklasse, tabel) niet verwijderen wanneer er verwijzingen naar worden gehouden, omdat ze impliciet zijn vergrendeld. Dat gezegd hebbende hoeft u zich geen zorgen te maken dat iemand een dataset uit uw handen zal verwijderen terwijl u er nog steeds naar verwijst. Dit kan gebeuren voor op INAME gebaseerde instanties, maar niet voor actuele live objecten in de geodatabase.

Dat betekent echter niet dat u de referenties vrij kunt houden. Vooral in een omgeving met meerdere besturingssystemen, waarbij elke versie wordt vertegenwoordigd door een afzonderlijke verwijzing naar IWorkspace : wanneer de gebruiker de versie waarmee ze werkt, moet wijzigen, moet je meestal je referenties bijwerken.

Meer in het algemeen, vermijd het houden van algemene (statische) verwijzingen naar objecten die gerelateerd zijn aan de werkruimte, tenzij je een mechanisme hebt dat updates en releases vrijgeeft wanneer ze niet langer nodig zijn. Cacheverwijzingen in een toepassingsbrede uitbreiding en deze gedurende de gehele levensduur van de extensie behouden IS in feite ook een statische referentie. Ik beperk de cache meestal tot een enkele run van een functie.

Bekijk ook de ingebouwde cache-mogelijkheden van het schema, die een aanzienlijk effect op de prestaties kunnen hebben als ze correct worden gebruikt: Gebruikmaken van de schema-cache .

8
toegevoegd
+1 Het lijkt erop dat in sommige situaties de werkruimtefabriek singleton referenties naar werkruimten blijft, ook al heb je al je referenties in je extensie vrijgegeven. Heb je dit gezien? Ik heb gehoord dat dit kan worden gecontroleerd door te kijken wanneer arcsde verbindingen aan de serverkant vrijgeeft. Soms worden verbindingen pas vrijgegeven als de app wordt afgesloten.
toegevoegd de auteur saint_groceon, de bron