A key element in database functionality is the transaction. A transaction represents a logical group of data-based operations that make up a complete operational task. There are two types of database transactions: short or long.

• Short Transactions—Short transactions are edit operations that are completed in a matter of seconds. Examples would include automated bank teller transactions or record updates.
• Long Transactions—Extended editing operations, which may involve many short transactions and a number of database editors, are referred to as long transactions.

Problems with short transactions

Locks are managed internally in the database and are acquired and released based on actions taken by a user, such as COMMIT or ROLLBACK operations. When a short transaction completes, the locks are released. Although short transactions work well in situations where critical applications require immediate access to a consistent view of the data, they are not well suited to the type of editing tasks required when updating geographic data.

In situations where many people are simultaneously editing the data, they perform edit tasks that take more than a few minutes to complete, the short transaction row-locking mechanisms adopted by many DBMS' would be prohibitively restrictive for other database users. This situation can also produce:

• Lock escalation—Row locks become page locks, page locks become whole table locks
• Deadlock situations—Two transactions are waiting for each other to unlock data, preventing any further updates to the data until the deadlock is resolved

These issues can have a negative impact on database performance and scalability. Thus, a more flexible approach to editing is required where interoperability exists between inherent connectivity and spatial relationships that define geographic data.

Long transactions and versioning

To support long transactions and provide a data management framework to accommodate multiple editors working on the same data at the same time, often over a long period of time, without duplicating the data, a data editing environment called versioning and an optimistic concurrency data-locking model were implemented. An optimistic concurrency data-locking model means no locks are applied to the affected features and rows during long transactions.

Although the absence of row locks introduces the inevitability of editing conflicts, versioning makes it easy to detect and resolve those conflicts. In real-world editing situations, conflicts are the exception rather than the norm. Given the small number of edits in comparison to the volume of data stored in a geographic database, the overhead of resolving these conflicts is relatively minor compared to the restrictions of prohibitive data locks or having to check features out of a central database to some local repository for the duration of a long transaction.