I have a long-running process. I want to prevent resource leaks or rogue database connections.
At intervals during the process I want to do this:
I've seen discussions such as:
Oh gurus, what is the final straight dope on this?
أكثر...
At intervals during the process I want to do this:
- get an ArcSDE (Oracle) workspace factory
- open a workspace from the factory (at which point I get an open database connection)
- get an existing feature class or table on the workspace,
- query the feature class or table, loop over the cursor doing my business
- then release/close everything such that:
- The database connection and table lock from ArcSDE/Oracle's perspective (as revealed by something like "sdemon -o info -I users" or a query of the sde.table_locks table) is closed/released.
- the process is resilient to ArcSDE/Oracle restarts (that is, I'm not leaving something hanging that won't work later after the nightly restart)
- Any RCW, COM references, and memory are released.
I've seen discussions such as:
- What are the rules for releasing ArcObjects from memory in .NET?
- what every arcobjects programmer should know about singletons
- how to release COM references
- interacting with singleton objects
Each workspace factory maintains a pool of currently connected, active workspaces that are referenced by the application. When any of the previously listed Open* methods are called, the workspace factory verifies if a workspace has previously been opened with a matching set of properties. If so, a reference to the existing instance is returned.
All of which suggests to me that I should release (e.g. ComReleaser class or equivalent Marshal.ReleaseComObject() loop), probably in this order:
- cursor
- featureclass/table
- workspace
- workspace factory
Oh gurus, what is the final straight dope on this?
أكثر...