Concurrency Locks

This section covers:

In Sisense Git Integration, a project is a representation of a local Git repository, which is also local to all of the users of the Sisense server and not just one user's computer. Because of this it is possible that multiple contributors will attempt to make updates in the same project at the same time.

Concurrency locking was added in order to protect Sisense asset updates and prevent conflicts between users such as overwriting each other's updates.

Watch this video for an explanation and demo of Concurrency Locking:

Concurrency Locking using Checksums

Concurrency locking is based on comparing the checksum of the project before taking some action, and then again during its execution.

The checksum consists of the following parameters and covers the following use cases:

  • The hash of the head is changed:
    • Were new commits added?
    • Was there a checkout to a commit or branch?
  • When head and HEAD are different:
    • Is the project in the detached HEAD state?
  • The amount of files or the staged changes in those files:
    • Has the staging area changed?
    • Has the working directory state changed?
  • Several users attempting to write to the same directory of the Git file system at the same time

Working with Concurrently Updated Projects

GUI

When the state of the project is changed while a user is trying to perform an operation, a modal dialog is displayed to inform the user and ask them to refresh the project.

It does not matter whether the project state was changed by another user, or by the same user in another browser tab. Validation is based on the project state changes, not the author of the changes.

API

For most of the non GET endpoints the x-git-status-checksum property is a required parameter. The value of this property is included in the response header of most API endpoints and can also be fetched via the dedicated GET /projects/{projectId}/status endpoint.

Locked projects

For emergency cases in which a project is trapped in a deadlock situation you can use the dedicated API endpoint PATCH /projects/{projectId}/unlock to unlock the project.

Best Practice

There is no silver bullet to prevent concurrent locking cases in the projects which are 'local' to several Sisense users at the same time. We recommend creating smaller projects that have a narrow asset scope dedicated to a particular domain, so that fewer people are likely to be working in the same project at the same time.

Having a smaller number of assets in a project will also have a positive effect on performance.