Take the 2-minute tour ×

After many months of programming with ArcObjects, I still feel somewhat unsure about two related issues:

For some operations, workspaces and datasets must be explicitly opened before they can be used. (For example, workspaces are opened via IWorkspaceFactory.Open(), ITables via IWorkspace.OpenTable(), etc.) On the other hand, there are operations that can be performed without having to open workspaces or datasets first (e.g. geoprocessing, or operations that accept INames as inputs).

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.

My first uncertainty is whether caching IWorkspace, ITable, etc. references could ever get me into trouble. More specifically, are there any ArcGIS operations, e.g. on tables, that require that there be no live references to "open" tables?

(I'm aware of only one potential problem source at the moment: If a workspace or dataset gets deleted, all cached references to it should be thrown away.)

My second, related uncertainty concerns how long I should cache workspace and dataset references (at most). Let's say I'm writing an ArcGIS extension; would it be OK to open required workspaces when the extension is loaded, and only reset the references when it is unloaded? Would it even be OK if I did the same for datasets?

Links to ESRI reference documentation (or insider knowledge) is most welcome.

share|improve this question
You may want to read the answer to this question gis.stackexchange.com/questions/15936/… to understand how an IName object (e.g. IWorkspaceName) differs from their connected counterpart (e.g. IWorkspace). Petr has the right answer, so no need to repeat :) –  Ragi Yaser Burhum Feb 22 '12 at 1:05

1 Answer 1

You will not be able to delete a dataset (e.g. a workspace, feature dataset, feature class, table) when any references are held onto it, as they are implicitly locked. That being said, you do not need to worry that somebody will delete a dataset from under your hands while you are still referencing it. This can happen for IName-based instances, but not for actual live objects in the geodatabase.

However, that does not mean you can keep references freely. Especially in a multiversioned environment, where each version is represented by a separate IWorkspace reference: when the user changes the version she's working with, you typically need to update your references.

More generally, avoid keeping global (static) references to any live workspace-related objects, unless you have a mechanism in place which updates and releases them when they are no longer needed. Caching references in an application-wide extension and keeping them for the whole lifetime of the extension IS effectively a static reference as well. I usually limit caching to a single run of a function.

Also, take a look at the built-in scheme cache capabilities, which can have a significant performance impact if used correctly: How to leverage the schema cache.

share|improve this answer
+1 Seems like in at least some situations the workspacefactory singleton keep references to workspaces, even though you may have released all your references in your extension. Have you seen this happen? I've heard this can be verified by watching when arcsde releases connections on the server side. Sometimes connections don't get released until app shuts down. –  Kirk Kuykendall Feb 21 '12 at 17:10

Your Answer


