Session locking shouldn’t be too hard, it’s mainly another measure to prevent multiple servers attempting to overwrite data at the same time. Here’s a brief structure:
-
When the player joins, their data is retrieved. Data in the data store is updated with the current server’s JobId to lock the session. In this process, a check for a current lock is conducted. If a lock is found and the JobId is different to the current server’s JobId, the time the session was locked is checked and if it has been too long the lock is overwritten with the new lock.
-
When the player leaves, the
os.time()value is added to the data when saving and the session lock is removed. This indicates when the data was last written to, helpful when we need to check for an outdated lock. -
If a valid lock was found in step 1, we kick the player and don’t save their data because it is outdated. We then ask them to wait a bit before rejoining. This is because another server is currently trying to update the data store with newer data, helping to prevent data loss. We need to give this time to go through.
Basically, when checking for a lock, we need to check two things:
- Is the lock outdated?
- Was the lock created by this current server?
If both of these are yes, we can safely overwrite the lock with a new one.
I saw on your post in #development-discussion you mentioned HttpService… no you don’t need that at all. game.JobId is often used because it’s unique.