ArcGIS Server Banner

Geodatabase transaction management

Geodatabase transaction management
Release 9.3 E-mail This TopicPrintable VersionGive Us feedback
Transactions are packages of work that make changes to databases. GIS databases, like other database applications, must support update transactions that enforce data integrity and application behavior. In many cases, users can exploit the DBMS's transaction framework for managing edits and updates to geodatabases.

However, GIS users universally also have some specialized transactional requirements. For example:

Additionally, users need to be able to undo and redo changes. Editing sessions can span several hours or even days. Often the edits must be performed in a system that is disconnected from the central, shared database. And so forth.

Because GIS workflow processes may span days or months, the GIS database must remain continuously available for daily operations, where each user might have a personal view or state of the shared GIS database. In a multiuser database, the GIS transactions must be managed on the DBMS's short transaction framework. The ArcSDE technology plays a key role during these operations by managing the high-level, complex GIS transactions on the simple DBMS transaction framework.

GIS users have many cases in which long transaction workflows are critical. In most instances, these are made possible through the use of a multiuser DBMS and ArcSDE to manage updates to the central GIS database using versioning, which you can read more about below.

The following are examples of GIS data compilation workflows that require a version-based transaction model:

The geodatabase transaction model -- Versioning

The geodatabase mechanism for managing these and many other critical GIS workflows is to maintain multiple states in the geodatabase and, most important, to do so while ensuring the integrity of the geographic information, rules, and behavior. This ability to manage, work with, and view multiple states is based on versioning. As the name implies, versioning explicitly records versions of individual features and objects as they are modified, added, and retired through various states. Each version explicitly records each state of a feature or object as a row in a table along with important transaction information. Any number of users can simultaneously work with and manage multiple versions.

Versions enable all transactions to be recorded as a series of changes to the database through time. This means that various users can work with multiple views or states of the geodatabase. The goal is open, high-performance multiuser access. For example, the system must go fast and must productively support the use of datasets containing hundreds of millions of records accessed by thousands of simultaneous users.

The geodatabase transaction model based on versions is relatively simple—updates are recorded in change tables.

Versions explicitly record the object states of a geodatabase in two delta tables:

Simple queries are used to view and work with any desired state of the geodatabase; for example, to view the database state for a point in time or see a particular user's current version with his or her edits.

ArcSDE plays a critical role in versioned geodatabase applications and is used to manage long transactions in each DBMS by leveraging its short transaction framework as well as to work across different DBMSs.

Version tables in the geodatabase

In the example above, a parcel (number 45) is updated to become parcel number 47. Using versioning, the original parcel is saved in the Deletes table and the new parcel is saved in the Adds table. Other meta tables record version information about the transaction such as the time and sequence of each update, the version name, and the state ID of each update. Each version also has its own security and access privileges.

This enables most users to work with the default version while various editors are simultaneously making updates against their own versions of the database over time.

Numerous updates can be made against each version, and users connect to and work with the update version as they make additional edits to the data. When users are ready to share the updates with the rest of the enterprise, a reconcile and post operation is performed to commit the edits held in the update version to the main (Default) version. A resolution process is used to identify and reconcile any potential conflicts during this process.

To learn more about versioning, see Understanding versioning.