Lock Service
Introduction
This page explains the design of lock service and types of locks that are possible with mechanism to lock a resource and unlock it with different possibilities.
Background
When a user want to lock a resource if we take an example of a content creator editing a content which is available for other creators to collaborate there is a possibility of content being updated by other party without knowing creator of content who is editing at the same time in this scenario we need to lock or protect the content being modified by other creator and as sunbird which is possible if the resource locked and it will be available to other creators when the current user who locked that content which similar to the operation system threads problem where multiple threads want to access same resource which handled using mutex (mutual exclusion) we need to have the lock service as generalized solution for other use cases so that it can be used across the sunbird services to protect a resource whenever there is possibility of accessing multiple services or users.
Problem Statement
Locking and unlocking of resource have multiple use cases which lock service should support
Locking a resource by a user or system or service
Unlock a resource by same user or system or service who acquired the lock
Force unlock a resource by admin or other system or service, in case of race condition where the user / system is unable to unlock the resource
Auto unlock / Time based unlock
Request for lock by user or system when a lock is acquired by another system or user
Solution 1 - storing lock in cassandra and unlocking with db operations and using TTL for auto unlock
In this solution we will be storing lock and it's info in cassandra table which will have the interface methods or api's to acquire the lock and release the lock
and the below is the table structure for it
Lock Table
Column Name | Data Type | Description |
|---|---|---|
resourceId | text | Resource id which is locked it is primary key |
resourceType | text | Type of the resource eg: content,org, user |
resourceInfo | text | Resource meta data |
creatorInfo | text | Additional information of the user / system who acquired the lock |
createdBy | text | User or service id who acquired the lock |
createdOn | timestamp | Time when the lock is acquired |
deviceId | text | The device Id of the user |
expiresAt | timestamp | Time at which the lock will expires |
here each row will have the TTL (Time To Leave) which will be configuration (By default 30 min) when a user gets the lock he will the time when the lock will be expires and he can refresh the lock before it expires the lock will provide another api to release it.
Below are the api Request and Response for lock service
API
Create
POST - v1/lock/create
Headers:
Authorization : "" //Bearer <token>
x-authenticated-user-token: "" // user token
Content-Type: "application/json"
X-device-Id: "" // device Id generated using fingerprint2 js lib from client
REQUEST BODY :
{
"id": "api.lock.create",
"ver": "1.0",
"ts": "YYYY-MM-DDThh:mm:ssZ+/-nn.nn",
"params":
,
"request":
}
RESPONSE :
{
"id":"api.lock.create",
"ver":"1.0",
"ts":"YYYY-MM-DDThh:mm:ssZ+/-nn.nn",
"params":
,
"responseCode": "OK",
"result":
}