What is a transaction?
A transaction is an application-defined unit of work performed against a database. A transaction starts, modifications are made against the database, and the transaction is committed or rolled back. Once the transaction is committed, the changes made by the transaction become visible to other users and applications.
Transactions have the following standard "ACID" properties on which users and applications have come to rely:
Atomic—A transaction exhibits "all or nothing" behavior. If it is committed, all its changes apply to the database. If it is rolled back, none of its changes apply.
Consistent—A transaction leaves the database in a consistent state.
Isolation—A transaction can isolate its changes from other transactions until it commits them. Other users do not see the work internal to the transaction while it is in progress.
Durable—Once a transaction commits, its results are persistent.
To achieve these properties, DBMSs use a variety of locking mechanisms to ensure that multiple concurrent transactions are shielded or isolated from each other.
Transactions and geographic data
In most applications, each transaction involves a small number of operations that can be completed in a fraction of a second or in a minute or two at the most. Withdrawing money from a bank account, updating hours worked in a payroll application, and entering a medical record are all examples.
In some respects, geographic data is no different. Updating data such as a customer address or the zoning designation of a parcel is an operation that could be completed in a short transaction taking one or two minutes.
Often, though, you need to spend one or two hours graphically moving, modifying, and adding data to complete a work order. There are also cases where you need to work on a transaction for days or even months to complete all the edits such as for an engineering design. Even though you may make a very large number of changes, you still want to commit them as a single long transaction.
