Forum BigDB Save

Discussion and help relating to the PlayerIO database solution, BigDB.

Save

Postby sebas77 » August 28th, 2013, 5:49 pm

After all this time using playerIO API, I am still not sure which Save function I should use and when. I always use in every case public void Save(Callback successCallback, Callback<PlayerIOError> errorCallback);. Is this wise?
sebas77
Paid Member
 
Posts: 137
Joined: June 25th, 2013, 12:09 pm

Re: Save

Postby Henrik » August 28th, 2013, 9:12 pm

Yes. This way you get both callbacks and can react to both successes and errors.
Henrik
.IO
 
Posts: 1880
Joined: January 4th, 2010, 1:53 pm

Re: Save

Postby sebas77 » August 30th, 2013, 2:34 pm

thanks, but I wonder if I should use the one with the optimistic lock instead, like this one

Code: Select all
public void IncrementMonstersKilled(var inc) {
   //Load the object MonsterStats from the GameStats table
   PlayerIO.BigDB.Load("GameStats", "MonsterStats",
      delegate(DatabaseObject result) {
         //Add inc to the Killed value.
         var killed = result.Get("Killed");
         result.Set("Killed", killed + inc);
         result.Save(true, null, delegate(PlayerIOError error) {
            if (error.ErrorCode == ErrorCode.StaleVersion) {
               //If someone else updated before us, try again
               IncrementMonstersKilled(inc);
            }
         });
      }
   );
}


Also I wonder if the optimistic lock makes sense only if the same property is overwritten or it must be used also if a whole object change. Example, I have an object with property1 and property2, one piece of code modifies and changes property1, the other piece of code modifies and changes property2, both pieces of code save the same object.

also, as long as we talk about server side code, do you think it is wise to keep on retrying for ever until the saving worked?

and as last question, will an existing databaseobject be saved if I call save but the properties are actually not modified?
sebas77
Paid Member
 
Posts: 137
Joined: June 25th, 2013, 12:09 pm

Re: Save

Postby Henrik » September 1st, 2013, 6:33 am

sebas77 wrote:thanks, but I wonder if I should use the one with the optimistic lock instead, like this one


If you have several instances of the same object floating around, for example if I can be on a different game server, load up your object, and make changes to it, while you are on your game server, changing your object as well, then you need optimistic locking to ensure that we don't overwrite each other's changes.

But if you're manipulating a single instance from different threads, then you won't need optimistic locking, since all changes happen in the same place, and whoever calls Save() will send whatever changes everyone has done to the object for saving.

sebas77 wrote:Also I wonder if the optimistic lock makes sense only if the same property is overwritten or it must be used also if a whole object change. Example, I have an object with property1 and property2, one piece of code modifies and changes property1, the other piece of code modifies and changes property2, both pieces of code save the same object.


That might work, but neither context would "know" that the actual object has changed, and that they both need to reload to have the latest version of it.

sebas77 wrote:also, as long as we talk about server side code, do you think it is wise to keep on retrying for ever until the saving worked?


Absolutely not. Figure out why it failed, and then depending on how it failed, perform the right action to ensure your retry won't fail.

sebas77 wrote:and as last question, will an existing databaseobject be saved if I call save but the properties are actually not modified?


Nothing will be sent over, because there are no changes to send over, but of course your databaseobject will be saved, because what's on disk is the same as your instance of it.
Henrik
.IO
 
Posts: 1880
Joined: January 4th, 2010, 1:53 pm

Re: Save

Postby sebas77 » September 2nd, 2013, 3:33 pm

Henrik wrote:
sebas77 wrote:thanks, but I wonder if I should use the one with the optimistic lock instead, like this one


If you have several instances of the same object floating around, for example if I can be on a different game server, load up your object, and make changes to it, while you are on your game server, changing your object as well, then you need optimistic locking to ensure that we don't overwrite each other's changes.

But if you're manipulating a single instance from different threads, then you won't need optimistic locking, since all changes happen in the same place, and whoever calls Save() will send whatever changes everyone has done to the object for saving.


So the optimistic lock is NOT the default behavior, is it?
sebas77
Paid Member
 
Posts: 137
Joined: June 25th, 2013, 12:09 pm


Return to BigDB