Hi,
I'm aware that Brendan always recommends to use seperate keys per PlayFabID when writing to SharedGroups. However, I can't use this in my use case.
Is there a best practice or some guidelines on how to achieve a lock / mutex like behaviour from CloudScript? Is a global scoped var OK in this case?
Thanks.
Unfortunately, that wouldn't give you a truly reliable locking mechanism. What's the feature you're attempting to implement? Knowing that would help us to be able to best advise you on a solution.
Since I'm saving each room/game/match data, including Photon room state, in a single key/value and my game is 1vs1, both players can write and read SharedGroup data simultaneously. My game is "round based", every new round each player can play a move "without waiting for the other one" so this makes things a bit "non deterministic" (although I'm trying to avoid a case where players "send moves at the same time" but I have to detect it and fix it in case it happens). Also there are other in-game events, like join or use of powerups, that trigger a read/write to the SharedGroup. I have no full control, either from client or CloudScript, over the order of the sequence of the events.
Besides, I'm doing read/write to SharedGroups in a data polling handler to detect timeouts and sync client data.
So unless I make a SharedGroup per room/game/match with each key binded/linked/mapped to or reserved for a unique player I'm still at risk of corrupting game data. I did not witness this already during development but I'm trying to make sure it doesn't happen.
BTW I'm using a free month trial of loggly to have better logs from CloudScript and it's helping us a lot!
We also love Loggly - extremely useful in tracking on any issues which occur in titles. :)
For your scenario, the problem comes if you want to have an unlimited number of "slots" for active games the player is in. If you limit that, you could either use one Shared Group Data, tracking on each player's moves with a unique Key, or even a small set of Shared Group Data object, using the opponent's PlayFab ID modulo N, where N is the number of Shared Group Data objects you're using to track all the game sessions. If you can have multiple games open with the same player, of course, you'll need to also add something to the Key to help differentiate it. That's the route I'd go, as realistically only a true locking mechanism would work for this - or a "compare and swap" operation - but that would have to be implemented in the service code directly for it to be effective. The compare-and-swap is something we do want to do when we can get it prioritized, but that's likely to be a while, yet.
After double checking, currently, Photon webhooks are queued and processed one by one. I'm relieved and now I can only worry about the I/O operations to SharedGroups outside webhooks which are less frequent. So I don't have to change the whole design again for the nth time.
Perfect, then! Let us know if you run into any issues with the implementation.
