are changed until the transaction is completed (either merged or
rolled back). These concurrency control techniques, however,
are insufficient for handling applications that must support
long-duration transactions.
3.1 Concurrency Control
The notion that a GIS transaction is a sequence of short-
duration transaction is not necessarily valid, as it implies a total
ordering of short transactions. A more flexible approach is to
view a GIS transaction as a set of short-duration transactions,
with some of the short transactions running in parallel. It will,
in general, form a hierarchy, where the child transactions of the
transaction at a given node can be executed in parallel.
o
or
©
938) 0)
Figure 3.1. A hierarchy of user's transaction
The model uses a series of short transactions and multiple data
versions to implement a complete long-transaction event that
maintains atomicity and concurrency. Changes are stored in the
database as different workspaces. Users are permitted to create
new versions of data to update, while maintaining a copy of the
old data. The ongoing results of the long transaction are stored
persistently, assuring concurrency and consistency.
A workspace is a virtual environment that one or more users can
share to make changes to the data in the database. A workspace
logically groups collections of new row versions from one or
more version-enabled tables, and isolates these versions until
they are explicitly merged with production data or discarded,
thus providing maximum concurrency. Users can perform a
variety of operations involving workspaces: create, refresh,
merge, roll back, remove, compress, alter, and other operations.
Users in a workspace always see a transactionally consistent
view of the entire database; that is, they see changes made in
their current workspace plus the rest of the data in the database
as it existed either when the workspace was created or when the
workspace was most recently refreshed with changes from the
parent workspace (Fig. 3.1.).
The possible conflicts, which are differences in data values
resulting from changes to the same row in a workspace and its
parent workspace, are automatically detected. The conflicts
must be resolved before merging changes from a workspace into
its parent workspace. The several types of locking mechanisms
for avoiding conflicts are described in Section 3.2.
3.2 Savepoints
Savepoints are points in the workspace to which row changes in
version-enabled tables can be rolled back, and to which users
108
can go to see the database as it existed at that point. Savepoints
are usually created in response to a business-related milestone,
such as the completion of a parcel subdivision or parcel merge
procedures. A savepoint is a point in the workspace to which
data changes can be rolled back. The rollback is accomplished
by deleting the row versions that contain the unwanted changes.
An explicit savepoint 1s a savepoint that is created and named
by user/application. User/application can later roll back changes
in version-enabled tables to the savepoint, or can go to the
savepoint to view the state of the entire database (including
versioned rows) at the time the savepoint was created.
In addition, implicit savepoints are created automatically
whenever a new workspace is created. An implicit savepoint is
needed so that the users/applications in the child workspace get
a view of the database that is frozen at the time of the
workspace creation.
The history option allows timestamp changes made to all rows
in a version-enabled table and to save a copy of either all
changes or only the most recent changes to each row. If
user/application keeps all changes when version-enabling a
table, a persistent history of all changes made to all row
versions is kept, and enables users to go to any point in time to
view the database as it existed from the perspective of that
workspace.
3.3 Lock Management
In addition to locks provided by regular database transactions,
there are two types of version locks. These locks are primarily
intended to eliminate row conflicts between a parent workspace
and a child workspace:
e Lock at the workspace level
if the data changes are in one or a few workspaces, or if we
want all data changes in the workspace to be locked.
e Lock at the session level
if the data changes are being made in many workspaces. When
locking is enabled for a session, rows in all workspaces in
which the session participates are locked.
e Lock specific rows
either to lock the rows before they are updated or to
automatically lock rows after they are inserted.
Workspace locks or session locks persist for the duration of the
Workspace or session, respectively, or until the workspace is
merged or rolled back. Like standard database locks, these locks
can be exclusive or shared:
e Exclusive locks
once an exclusive lock has been placed on a record, no other
user in the database can change the record except for the session
(user) that locked it. When exclusive locking is enabled for a
user, any row that the user changes is locked exclusively. In
addition, the parent row to that row is also locked exclusively.
Thus, exclusive locking can be used to eliminate data conflicts
between a child and its parent workspace.
e Shared locks
Once a shared lock has been placed on a row, only users in the
workspace in which it is locked are allowed to modify it. Shared
locks are also placed on the parent version of the row, thus
protecting the row from conflicts. The benefit of shared locks
over exclusive locks is that all users in the workspace where the
row is locked can access the row for changes. An ideal use for
this kind of lock is on a row that needs to have no conflicts with
its parent, but that needs to be changed by a collection of users
particip:
individu
An ove
cadastre
transacti
GIS de
tempora
impleme
relation:
Worksp:
enabled
enabled,
the data.
of the d
inserting
usual w.
transacti
long-trai
concurre
All chai
short tr
different
of data t
ongoing
assuring
Accordi:
our data
records
concept
41 Tei
After a t
automat
are inte
