Sign In Register

How can we help you today?

Start a new topic
Answered

Locking capabilities of Runtime collection

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

 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


1 person has this question

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

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

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

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!!

+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?

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. 

Login to post a comment