question

andrearossini avatar image
andrearossini asked

Concurrency Player Data Read/Write

Hi,

we are trying to implement Tapjoy Self Managed Currency. We have written a web server that can handle Tapjoy callbacks.

Our web server writes user player data when tapjoy reward callback is performed. The idea is allow the client to consume this data through cloud script.

The problem is: how PlayFab handle concurrency operations on Player Data?

If we have a cloud script function that:

- Read a player data entry

- Modify that entry

- Write the new entry

Is that possible that 2 instances of cloud script (called from an external web server via http) create an execution like:

- A Read

- A Modify

- B Read

- A Write

- B Modify

- B Write

which is equal to execute just B (ignoring A)?

Thank you.

Best regards,

Andrea

10 |1200
Toggle Comment visibility. Current Visibility: Viewable by all users

Up to 2 attachments (including images) can be used with a maximum of 512.0 KiB each and 1.0 MiB total.

1 Answer

·
brendan avatar image
brendan answered

Yes, that's absolutely the case. Player data is really intended for a single player to use, not a group of users. What is the actual gameplay design that you're trying to achieve? Starting top-down would be the best approach to evaluating your options. How is your self-managed currency set and used? How often? By whom?

6 comments
10 |1200
Toggle Comment visibility. Current Visibility: Viewable by all users

Up to 2 attachments (including images) can be used with a maximum of 512.0 KiB each and 1.0 MiB total.

andrearossini avatar image andrearossini commented ·

Hi,

we are trying to implement Tapjoy self managed currency system with PlayFab.

When Tapjoy detect a reward for a specific player, it calls a custom URL. We have written a web server that can handle this request. The goal is to find a solution that allow us to notify a player when he has a reward.

We have 2 ideas:

A) Our web server does a Cloud Script call and the Cloud Script write user player data, adding a structure like {"reward": "100"}. So the client, in some points, check for this strucutre. Concurrency can create some problems in this solution.

B) In our Game we have 2 currency. We were thinking about create 2 other currencies and use them as a reward pool. If client see a value > 0 in those currencies, it means there is a pending rewards. To implement this solution we need to be sure that AddUserVirtualCurrency and SubtractUserVirtualCurrency are concurrency-safe: is that true?

Do you see any other way to achieve our goal?

Thank you.

Andrea

0 Likes 0 ·
brendan avatar image brendan andrearossini commented ·

In either case, one issue is that you'll still have to poll from the client. As long as that's only once every couple of minutes that'll be fine, no worries.

But for B, the answer is that no, we cannot guarantee concurrency of those operations. If there are multiple add/subtract calls that come in at the same time, there is a chance the could step on each other. It should be rare, but it is technically possible.

0 Likes 0 ·
andrearossini avatar image andrearossini brendan commented ·

Yes, the client check in both case is performed just in specific client-flow points. So it should be done once every X time.

The problem is to find a way to handle conccurency problem.

0 Likes 0 ·
Show more comments
jsbourdon avatar image jsbourdon commented ·

Are user data CAS operations still in the planning? That would be quite useful.

-1 Like -1 ·
brendan avatar image brendan jsbourdon commented ·

Can you describe what it is you're trying to implement, exactly? We've made a number of changes to the service and have others in process, so it's possible there are more options for you today (or in the near future). If you're specifically asking about the existing User Data service (not Entity data), then no, the issue described above is still the case.

0 Likes 0 ·

Write an Answer

Hint: Notify or tag a user in this post by typing @username.

Up to 2 attachments (including images) can be used with a maximum of 512.0 KiB each and 1.0 MiB total.