Sign In Register

How can we help you today?

Start a new topic
Answered

Spark lockKey Questions

I have a custom runtime collection that contains custom data on each player (call it playerState), where each document is specific to each player.


Unfortunately there are many arrays of subdocuments in each doc that need updating, and since mongo is really terrible with that, I often need to query an array, modify the elements in cloud code, and re-"$set" the array. This is dangerous because some other script could have changed the array in the meantime and those changes would be overwritten. Thankfully Gamesparks recently introduced Spark.lockKey(). But I have some questions pertaining to it.


For my use case should I use the playerId as the lockName since each document revolves around one specific player?


What's a reasonable time for tryMillis? I know cloud code has an execution time limit, so I would certainly want to leave time for my script to finish after it acquires the lock, but not much else to go on.


Since the documentation states the key automatically is released when the script terminates, is there any point to even manually unlock the key at the end of the script? I know I can release it sooner if I'm finished with the document earlier, but if I don't update the doc til the end of the script is there a point to call unlock myself?


Finally, is unlock actually guaranteed to be called automatically when the script ends in EVERY case (i.e. even when the script fails because of syntax errors in the code?)


Best Answer

(Raised a ticket with the questions and got a response which I'm posting here in case anyone else has the same questions. Mods can mark this as answered).


Hi Ryan,


For my use case should I use the playerId as the lockName since each document revolves around one specific player?


This would depend on the use case. You say each document is specific to each player, if its that particular player document you'd like to lock then I'd say the playerId would be a good value to use.


What's a reasonable time for tryMillis? I know cloud code has an execution time limit, so I would certainly want to leave time for my script to finish after it acquires the lock, but not much else to go on.  


Again this depends on the use case. Have you any other scripts that would be accessing this information at this time? Ideally the best case would be to update the information as quick as possible and avoid long running scripts.


Since the documentation states the key automatically is released when the script terminates, is there any point to even manually unlock the key at the end of the script? I know I can release it sooner if I'm finished with the document earlier, but if I don't update the doc til the end of the script is there a point to call unlock myself?


The unlock feature would be for just releasing the lock if it's needed else where, if it's not needed I would see no problem in letting the automatic unlock do the job.


Finally, is unlock actually guaranteed to be called automatically when the script ends in EVERY case (i.e. even when the script fails because of syntax errors in the code?)


Yes, Spark.unlock() should be called when a script terminates, regardless of what caused the script to end.

If you have any further questions, please don't hesitate to get in touch.


Kindest regards,

 - Steve



1 Comment

Answer

(Raised a ticket with the questions and got a response which I'm posting here in case anyone else has the same questions. Mods can mark this as answered).


Hi Ryan,


For my use case should I use the playerId as the lockName since each document revolves around one specific player?


This would depend on the use case. You say each document is specific to each player, if its that particular player document you'd like to lock then I'd say the playerId would be a good value to use.


What's a reasonable time for tryMillis? I know cloud code has an execution time limit, so I would certainly want to leave time for my script to finish after it acquires the lock, but not much else to go on.  


Again this depends on the use case. Have you any other scripts that would be accessing this information at this time? Ideally the best case would be to update the information as quick as possible and avoid long running scripts.


Since the documentation states the key automatically is released when the script terminates, is there any point to even manually unlock the key at the end of the script? I know I can release it sooner if I'm finished with the document earlier, but if I don't update the doc til the end of the script is there a point to call unlock myself?


The unlock feature would be for just releasing the lock if it's needed else where, if it's not needed I would see no problem in letting the automatic unlock do the job.


Finally, is unlock actually guaranteed to be called automatically when the script ends in EVERY case (i.e. even when the script fails because of syntax errors in the code?)


Yes, Spark.unlock() should be called when a script terminates, regardless of what caused the script to end.

If you have any further questions, please don't hesitate to get in touch.


Kindest regards,

 - Steve




1 person likes this
Login to post a comment