Skip to end of metadata
Go to start of metadata

Goal

The goal of collision management is preventing users from editing objects without informing about changes done by sibling users, when multiple users works on same project.

Definitions

arKItect session – a session of work in arKItect. Session starts when Project is opened and ends when Project is closed. Each session described by unique number stored on server side, allowing to distinguish between different arKItect sessions, even opened on same PC with same user login.

HP –  History Point – an unique (within the Project) ID for each atomic operation.  Stored on the server side in historyCM table.

Collision – user A tries to change something about object in the area changed by user B after the 'user A load project' moment. Collision could be accepted, meaning that user A informed about changes done by user B but still wants to continue his work,  or declined, meaning that user A don`t want to perform his changes on objects changed by user B. 

Blocking Collision  – a collision which could not be 'accepted'. I.e. User A tries to change an object, but there are changes in matrix done by user B, so user A should reload his project.

arKItect session characteristic

Here is a detailed description of arKItect session parameters, used for collision management:

  • Session ID – an unique (per project) number, associated with each unique arKItect session at the [Project Open] moment. Even if two arKItect sessions opened from same computer with same logins - they will have different session IDs. This number allows to distinguish on server side between changes done by different arKItect sessions.  
  • HP ID – the last history point known for the project at the loading moment. Each atomic operation has a HP, so the HP of the last change done on the Project could be called 'current HP'. At the loading moment this ID stored for the arKItect session, allowing to distinguish between 'changes know for the session' and 'changes done by other users after the loading moment for the given user'
  • Accepted HP list – the list of non-blocking history actions ‘accepted’ by user. Filled when the collision appears for an object, and user agrees with actions done by other person in same project. In other words this list keeps the list of actions done by other users and marked as known by the user working with given arKItect session

Request structure  

Each request sent by arKItect contains some additional info:

  • [ArKItect session characteristic]
  • [action characteristic (object ID, list of direct/visible parents)]
  • [Regular Request data]

Each answer from server side contains

  • the list of collisions (if collisions appear)
  • [regular answer] if no collision appears

arKItect logic

Here is an image describing arKItect behavior performing request with collision management:

 

If no collision appears for the arKItect request - request performs on the server side in regular mode without additional operations.

if the the blocking collision appears - the request will be cancelled, project should be reloaded manually.

If regular collision appears - user can accept it. the Request will be resent, but new collisions could appear at this time. In this case checking collisions process should be repeated.

Here is an example of communication between two arKItect clients and server when two users work on same object in the same time:

Example of arKItect dialog showing a collision.

What needs to be verified and considered as a collision

Here is a table of dependency between object changes treated as collision

  • No labels