I have profile service integrated in my game, and have a datastore key that every server needs reading and writing access to at potentially the same time. I was wondering how I’d go about doing that, since it applies a session lock to the profile. Is there any way to disable the session lock for that profile specifically, or to get around it?
Session locks can’t be disabled but you can steal the session. Check out the documentation for LoadProfileAsync for more information.
In my opinion ProfileService isn’t good for game-wide data on the same key because of the session locking feature and how game-wide data probably doesn’t need to be locked to a session. I’d prefer creating my own system to handle that DataStore.
3 Likes
I agree that in this situation a custom Datastore would be better. I don’t really trust myself to be aware of all things needed to make a reliable one though. Do you know the things I need to consider while making one, especially in this situation?
There are three things I would personally consider for this kind of system.
- Do you need DataStores for your use case?
- How often are servers expected to write to the DataStore?
- Will your system run into DataStore limitations? How can you work around them?
Those are the three main points. The rest are all nuances of the use case itself.
I don’t think I’d ever have a use case where I’d need one key in one DataStore that all servers of all places of an experience would need to read and write from. Sounds fairly unique.
I need it because I’m saving a waiting list full of players waiting to join a match, that would look something like this.
local gamemode1name = { {playeruserid, playeruserid,...}
local gamemode2name = {playeruserid,playeruserid,...}
--and so on for the amount of gamemodes
The game mode names are the keys, in the datastore. When a player signifies they want to joins a match, we add them to the waiting list of the relevant game mode, and, using messaging service, subscribe to receive a “retrieveplayer2” message.Each server checks every second if the top index in each game mode is in them, then reserves a server and sends the “retrieve player 2 message” to the server that index 2 belongs to, with the reserve server code,the player user id, and other relevant info. Then the server removes the first 2 indexes from the list. All the servers subscribed to the message check if the player sent is in them, and if so, teleports them to the reserve server. This complicated way was all I could think of 
Assuming there can be multiple servers of one game mode and you aren’t doing cross-server matchmaking, you probably wouldn’t need DataStores for this. You could either store session data on the current server or let Roblox automatic matchmaking take care of most of the heavy lifting.
I’m not sure if my case is applicable to yours or not but I work on an RPG game that involves creating parties to go to dungeon places with. We just store the party members and their relevant UserIds in a table with the current server, then teleport them when they’re ready to be sent off. I’m planning to rewrite the backend a little bit to use memory stores/temporary DataStores for working with match data but never regular DataStores, this isn’t data that should be permanent.
Just some thoughts. I’m just not particularly sure you need DataStores to accomplish your specific use case or there’s some way to do it without DataStores. Temporary DataStore’s release would easily resolve this use case since matchmaking is one of its use cases but without access to that it’s either using regular DataStores or workarounds, the former of which is less desirable than the latter.
I am doing cross server matchmaking 
Basically, my issue boils down to needing one table that every server reguIarly read and write to. While read the article about Datastore limits and they specifically said
“In particular, requests to a specific key can be throttled if it’s being requested from too many servers at once.”
On second thought, I think messaging service can completely solve my problem. When a new server is made, they’d subscribe to receive the updated table, and on when a message arrives they’d update a local table to reflect the contents. When a server needs to update the table for everyone, they’d just simply send a message to all the servers with the info the servers need to add.