Show TOC

Concurrency ControlLocate this document in the navigation structure

Use

Concurrency control defines a controlled way of allowing multiple users to simultaneously access the same resource in the Design Time Repository (DTR). Accessing a resource includes displaying, changing and deleting it.

The DTR allows multiple users to access the same resource at the same point in time. The constraints defined by the DTR for concurrent access of the resources in a repository are captured below:

  1. If a user has checked out a resource for deletion in a workspace, then no other user can check out the same resource for modification or for deletion in the same workspace.

  2. If a user has checked out a resource for modification in a workspace, then no other user can check out the same resource for deletion in the same workspace. But any other user can check out the resource for modification.

    Note

    The Design Time Repository perspective also offers an exclusive check-out function, which prevents other users from checking out the same resource in parallel.

Example

Two users, user1 and user2 trying to modify the same resource in the same workspace dev .

The following figure shows the Version Graph from user1 point of view after the resource is checked out for modification by the same user in the scope of an activity X .

Resource checked out by user1 in the scope of activity X

The following figure shows the version graph of the same workspace as seen by two different users. Version 2 is the current active version in the workspace. Version 3 in Activity X or in Activity Y, respectively, is the current working version for the respective user.

The figure on the left-hand side shows the version graph as user1 sees it after user2 checked out the resource. Version 2 is the current active version in the workspace. Version 3 in activity X is the current working version for user1 .

The figure on the right side shows the version graph as user2 sees he or she checked out the resource. Version 2 is the current active version in the workspace. Version 3 in activity Y is the current working version for user2 .

Now activity X is checked in by user1 .

The following figure shows the resulting version graph as seen by the two users.

The figure on the left-hand side shows the version graph as user1 sees it after he or she checked in the resource. Version 3 is the current active version in the workspace. Version 3 in Activity Y is the version checked out by user2 .

The figure on the right side shows the version graph as user2 sees it after user1 checked in the resource. Version 3 is the current active version in the workspace. The version 3 in Activity Y is the current working version for user2 .

Now when user2 tries to check in activity Y, a check-in conflict is reported. A conflict occurs between any two versions of a resource with a common predecessor when the version being checked in or integrated is not a predecessor or successor of the currently active version in the workspace.

In the DTR, there are two possible types of conflicts - check-in conflict and integrate conflict .

  1. A check-in conflict occurs when the version that is being checked in is not a direct successor of the currently active version in the workspace. The currently active version is called the 'Remote' or the 'Active' version. The version being checked in is called the 'Local' or the 'Conflicting' version.

  2. An integrate conflict occurs when you try to integrate an activity in order to make the contained version the active version of a workspace, while this workspace already contains a version of this file, which, however, is neither predecessor nor successor of the version in the activity. For more information, see Distributed Development .