Workspaces

A workspace is a long-time transaction that persists after process termination. Workspaces are used for storing temporary updates. As long as working in a workspace changes are not written to the database but to a special workspace area.

A workspace is like a transparent slide on top of the database. After finishing a series of updates that may take several days or weeks one may consolidate changes, i.e. storing all updates to the database or discard them.

Workspaces are identified by names and allocated by the database system. Usually workspaces reside in the same location as the database file(s).

The workspace features can be enabled running the Workspace database tool.

A workspace is a persistent transaction, which stores updates made by a user or group of users until the workspace is consolidated or discarded. Workspaces may form hierarchies, i.e. below a workspace, sub-workspaces might be defined, which act as nested transactions.

Instances updated are moved to the workspace currently activated. Data entries stored in a workspace ones can be updated only from within the workspace or subordinated workspaces, i.e. within a workspace hierarchy, only. Thus, workspace hierarchies behave similar to nested transactions.

In contrast to transient transactions several users may work in the same workspace but only one can consolidate or discard changes. After consolidating or discarding changes the workspace is cleared up, i.e. it remains as empty workspace.

One problem with long transactions is keeping the database consistent without blocking the whole system by locked instances and collections.

Example: One transaction adds an instance with a unique name ?Paul? in a workspace. This is not visible from other workspaces but, nevertheless, no other user is allowed to add ?Paul? again.

Hence the system must know in a way the state of the database, as it would look like when all workspaces have been consolidated. This is also important when checking update, insert or deletion rules, which may involve other instances.

For this purpose a shadow database will be creates as copy of the original database when enabling the workspace feature. The shadow database reflects the database state at any time as if all changes have been made directly in the database.

Thus, it becomes possible to refer to the states in the shadow database as well as to the states in the ?real? database without updates saved in workspaces.

In order to avoid concurrency conflicts, workspaces use pessimistic locking. Since indexes might be affected from changes, too, this would cause serious locking problems, when storing and locking indexes or part of indexes in the workspace.

Instead of locking indexes, key locks (or difference lists) are created for each collection (index) updated within a workspace. Difference lists record changes in indexes. Working with difference lists makes the system a bit slower, but improves accessibility. In order to get the current state for an index, difference lists are added along the workspace hierarchy.

When creating a workspace, a separate database file will be created for each workspace containing the updated instances and difference lists for key locks.

The original database remains unchanged, until data from a top level workspace has been consolidated. When consolidating a workspace, data stored in the workspace is moved one level up.

Workspace 0 (WS0) is an administrative workspace, which cannot be accessed as workspace within an ini-file or application.

Within a workspace one may create another workspace below the current one. When consolidating the lower workspace the changes are stored in the upper workspace but not in the database. When consolidating the upper workspace while lower workspaces are opened only the consolidated changes from lower workspaces are stored into the database. In this case the upper workspace is not completely cleared up since all instances that are in use in lower workspaces are still locked in the database.

A user can own workspaces. In this case only the user who has allocated the workspace is able to open it again. It is, however, also possible to create public workspaces that can be accessed by any user.

Usually, private workspaces are created by a user from within an application. The application itself takes care about user control. Public workspaces are created by administrators by establishing a workspace for a certain user group (as system or developer).

Whether a workspace is private or public depends whether it is created with user identification or not.

Similar to transactions, workspaces cause problems with conceptual integrity, which is described by a number of rules describing valid and invalid database states (e.g. ?no employee can earn more money as its boss?). When changing the salary for an employee from 4000 to 4500 and his boss earns 5000, everything is ok. Reducing the boss' salary to 4200, no, will be denied, since this is less than the employee income.

When, however, the first transaction is done in a workspace (UG1), and lowering the boss' income in another transaction (workspace UG2), no conflict will be signaled, since both transactions check against the current database state, and there, the employee still gets 4000. When consolidating both workspaces, conceptual integrity will not be checked anymore.

In order to avoid this type of integrity conflicts, the application may ensure, that related object instances are locked in the workspace, as well, i.e. when changing the income of an employee, the boss instance has to be locked in the workspace, too. This will reduce accessibility, since now, nobody will be able to change the income of another employee from within another workspace.

In contrast to transient transactions, the ?after image? of the database (database state after consolidating all workspaces) is known (workspace 0). Thus, integrity checks could also run against the after image database state.

This, however causes similar problems, when discarding a workspace later on.

The only save way is assuming the worst case scenario. By checking both, the before and after image, i.e. the state in the original database and the state in workspace WS0, violating conceptual integrity can be avoided. In this case, however, changes might be denied (e.g. because of before state), which practically should pass.

Since none of the described strategies is perfect, it should be up to the developer or user to decide.