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:
- 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.
Basically, due to the long-running nature of the process, I want to be really sure I haven't got resource leaks or rogue connections, and my process can survive ArcSDE/Oracle restarts.
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
And this, from which I quote
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:
- workspace factory
Then there are discussions like this where people do all that, and maybe even sprinkle in System.GC.Collect() and their database connection still lives.
Oh gurus, what is the final straight dope on this?