2

I have a geodatabase having relation classes, domains ,subtypes etc. When I am trying to open that featureclass in a multithreaded environment it often fails with error like
"Attempting to read proptected memory" or AccessViolationException

I wonder if this is because of geodatabase, may be it is getting hold of all the schema locks, I making a direct connect to oracle spatial 10g and no ArcSDE is installed.

Any Suggestions?

adhiman
  • 309
  • 2
  • 8
  • Are you connecting via Arccatalog or through some custom application? The question is tagged only with 'arcobjects', which hints this is a programming question. If so that should be spelled out as it will draw quite different answers – matt wilkie Oct 16 '10 at 05:03
  • 1
    also you might consider moving the "How to get schema locks...?" into the body of the question, and move the error message into the subject line. The error is the actual observed problem and no schema locks is your best guess at what is causing it, but at this point it is still speculation. There may be another more fundamental cause. – matt wilkie Oct 16 '10 at 05:07

2 Answers2

2

As said in the other answer, the multithreading nature is very likely to be the culprit. You can successfully work with ArcObjects in a multithreaded environment, but at the same time you need to understand certain patterns to follow and few things to avoid.

In your specific case, make sure that the workspace from which you are opening a feature class is only used on the very same thread on which it was instantiated. More generally - ArcObjects typically cannot be used across thread boundaries unless they are serialized/deserialized into a form which can be easily marshalled (as outlined in this post, for example).

If you haven't done so yet, I strongly suggest that you read this document: Writing multithreaded ArcObjects code.

Community
  • 1
Petr Krebs
  • 10,291
  • 1
  • 22
  • 33
  • +1 Any idea if the demise of DCOM at 10.1 means multithreading might get easier? – Kirk Kuykendall Apr 26 '11 at 02:06
  • @Kirk: I don't think so. Even if DCOM goes completely, COM stays with us for years to come. Writing multithreaded COM applications is very hard and I do not think ESRI will make the necessary investments on such an old platform. I do not see them switching to any other platform either, at least not anytime soon. – Petr Krebs Apr 26 '11 at 09:44
  • Also, I am a bit confused as to the demise of DCOM. On one hand, you can catch ESRI saying 10.1 will not break any APIs, on the other hand they say DCOM will not be possible. Still, I believe DCOM will remain, for example, for ArcGIS Server administration. Maybe they mean DCOM will be removed only from the ADF? – Petr Krebs Apr 26 '11 at 09:47
  • @Kirk, @Peter: the 'demise of DCOM' means that ArcGIS Server will not expose DCOM endpoints. I.e. you will not be able to connect to AGS using anything other than SOAP or REST. This means ADF, Engine, or Desktop for that matter will not be able to open a server context. It has absolutely no impact on the use of COM in plain ArcObjects as used in Engine apps, Desktop extensions or Server Object Extensions. All of those things will still be ArcObjects and thus COM-based. The upshot is that ADF local connection will break. So will anything else using IServerContext directly or indirectly. – Philip Apr 26 '11 at 19:59
  • @Kirk: To your point: the removal of DCOM from ArcGIS Server has no impact at all on writing multi-threaded desktop apps or extensions. Same pitfalls apply as always: only use your AO instances on the thread they were created etc. @Peter: Re. server administration: all server admin will be exposed as REST operations which will be used by a new ArcGIS Server Manager. No more DCOM, even for server admin (by extension: no more server admin using ArcCatalog!). – Philip Apr 26 '11 at 20:02
  • @philip, @peter thanks for clarifying. I wish I had time to attend this hopefully someone will summarize the meeting. – Kirk Kuykendall Apr 26 '11 at 20:09
  • Very appropriately for this discussion, the following blog post was just released: http://blogs.esri.com/Dev/blogs/arcgisserver/archive/2011/04/26/Considerations-for-ArcGIS-Server-developers_3A00_-A-look-toward-10.1.aspx – Philip Apr 27 '11 at 02:31
0

The multi-threaded aspect of your app may be your problem; since the ESRI api's are not thread-aware. They assume that if you are connecting that they own that object; so another process connecting in that same application to that same feature could find a lock.

Support for Multi-threading has been promised since 9.x but its a big migration path for ESRI due to the sheer number of COM objects in the ArcObjects API that need to be updated to support it.

D.E.Wright
  • 5,497
  • 23
  • 32
  • Saying that ArcObjects are not thread-aware is close, but not exactly correct. For example, all the singleton classes (e.g. workspace factories) are singletons-per-thread so that multithreaded scenarios can be supported (in a somewhat limited manner though). – Petr Krebs Apr 25 '11 at 22:21
  • But you also need to properly dispose of them to get them not to lock things up; that is more I guess what I was thinking. Its too easy to use sloppy programming that .Net will help with but the older COM stuff doesn't that leaves garbage around. – D.E.Wright Apr 25 '11 at 23:12
  • I agree with you, but releasing critical COM resources in a timely manner (and not relying on the GC in garbage-collected environments such as .NET) is just as important in a singlethreaded application as in multithreaded scenarios. – Petr Krebs Apr 26 '11 at 09:38