FAQ: How do I control the scope of a database transaction in the geodatabase?


How do I control the scope of a database transaction in the geodatabase?


It is very important for developers who are building multi-user applications to understand a session's transaction scope. Specifically, when within the geodatabase are database transactions started and committed. As well as, what ArcObject interfaces and methods are available for the developer to control the application's transaction.

By definition, a database transaction provides the ability for an application to either commit or rollback data modifications as one single unit of work. Within the transaction, the changes are visible to either the session performing the operation or other sessions based on their session's database isolation level.

The geodatabase exposes the ability for user applications to control the scope of a transaction based upon the application's requirements. When an application starts editing a workspace and calls IWorkspaceEdit::StartEditOperation, or within the editor IEditor::StartOperation, a database transaction is started. At this point all inserts, updates and deletes are one transaction until IWorkspaceEdit::StopEditOperation, or within the editor IEditor::StopOperation, is called. If the operation needs to be aborted, the application would perform an AbortOperation, which is equivalent to a database rollback.

If the developer needs to perform a transaction when not editing a workspace, the application can use the ITransactions interface. The interface provides methods to StartTransaction, CommitTransction and AbortTransction. If the application has already started a transaction on the workspace by calling StartEditOperation, then ITransaction::StartTransaction returns an error.

By default, if the application has not explicitly started a transaction by way of either the above examples, any inserts, updates or deletes are then committed after each operation and can not be undone. When performance is important, it is always faster to start a transaction and perform all operations as one single unit of work verses individually.

The above transaction scopes are applicable to all data sources, those registered as versioned and those that are not register as versioned. In addition complex data types such as, geometric networks and topologies, require the data to be versioned to start a transaction.