Locking capabilities of Runtime collection : GameSparks

J

Jo Huang

started a topic almost 7 years ago

Hi

From Platform Release 2016-04-15 ,

Story --- Runtime collections optimistic locking capabilities and versioning control to ensure 2 users cannot update the same collection at the same time (7137)

However I cannot find the doc of this feature.

Please help me how to use it.

Thanks,

Jo

Best Answer

C

Customer Support said almost 7 years ago

Hi Jo,
Jeff is correct. It is a built-in feature of Mongo-DB so you won’t need to do anything else to make it happen on your end.

David

J

Jeff Amiel

said almost 7 years ago

I believe it's a built-in feature of MongoDB - GameSparks simply started using that access mode...

J

Jo Huang

said almost 7 years ago

Hi

Thanks for reply, but I cannot find the related cloud code API from here

https://docs.gamesparks.net/documentation/gamesparks-service-cloud-code-api

How to make it happen when executing cloud code?

Jo

Customer Support

said almost 7 years ago

Answer

Hi Jo,
Jeff is correct. It is a built-in feature of Mongo-DB so you won’t need to do anything else to make it happen on your end.

David

J

Jeff Amiel

said almost 7 years ago

Follow-up - do we expect to get 'errors' on writes/updates that would require us to submit again (if the collection document had been updated since previously 'read')? Just trying to understand how this is being handled behind the scenes...

thanks!!

L

Luke Clark

said almost 7 years ago

+1 to Jeff's question. What exactly happens in this case?

Does the first write/update lock the collection and the other requests get queued and fulfilled in order? Or do the other requests throw an error we're supposed to handle?

Customer Support

said almost 7 years ago

Spark.Lock is intended to allow the concurrent sending of requests in the context of a Challenge. Both Players will send requests, while only one player will be in the locked area of code at a time.

So to answer your question, yes, one requests will attain the lock, it will write/update, then it will forfeit the lock, allowing the other request to write/update. You should not need to handle this on your end as it is a MongoDB feature.

Best Regards, Patrick.

A

Amarender Singh

said over 4 years ago

Hi All,

Just checking in, Is this locking capability also applicable on GameData Service?

Because In my use case I have a game data type which holds the data of a group of players. So if multiple users sent request to write that document at the same time what is the expected behavior.

I don't know how to test this.

Thanks

How can we help you today?