Using Communication Objects > SharedObject object > Avoiding shared object synchronization problems

Avoiding shared object synchronization problems

If more than one client (or a server application) can change the data in a single slot of your shared object at the same time, you must implement a conflict resolution strategy. Here are some examples:

Use different slots The simplest strategy is to use a different slot for each user that might change data in the object. For example, in a shared object that keeps track of users in a chat room, provide one slot per user and have users modify only their own slots.

Assign an owner A more complex strategy is to define a single client as the owner of a property in a shared object for a limited period of time. You might write server code to create a "lock" object, where a client can request ownership of a slot. If the server reports that the request was successful, the client knows that it will be the only client changing the data in the shared object.

Here's some server-side ActionScript that locks and unlocks a shared object to make sure the true highest score is returned to the game. Suppose the most recent highest score was 95, and player 1's score increased to 105, while player 2's score increased to 110. If no locking occurred, both players' scores could be compared to the most recent highest score, 95, or a collision could take place if both clients call updateHighScore simultaneously. You'd want to make sure that each player was compared to the highest score, regardless of whether it was the most recent highest score or any score currently coming in from all other clients. If you lock and unlock the shared object used to store the highest score, you can compare each score sequentially, and thus ensure that no comparison is lost.

application.onAppStart = function() 
{
	application.scoreSO = SharedObject.get("high_score_so", true);
	application.scoreSO.onSync = function(listVal) 
	{
		trace("got an onSync on scoreSO");
	}
}

application.onConnect = function(newClient,name,passwd) 
{
	newClient.updateHighScore = function(final_score) 
	{
		application.scoreSO.lock();
		if (application.scoreSO.getProperty("high_score_so") < final_score)
		{
			application.scoreSO.setProperty("high_score_so", final_score);   
		}
		application.scoreSO.unlock();
	}
}

Notify the client When the server rejects a client-requested change to a property of the shared object, the SharedObject.onSync event handler notifies the client that the change was rejected. Thus, an application can provide a user interface to let a user resolve the conflict. This technique works best if data is changed infrequently, as in a shared address book. If a synchronization conflict occurs, the user can decide whether to accept or reject the change.

Accept some changes and reject others Some applications can accept changes on a "first come, first served" basis. This works best when users can resolve conflicts by reapplying a change if someone else's change preceded theirs.

Use the send method to increase your level of control over changes to objects Rather than relying completely on SharedObject.onSync to manage synchronization activities, use the SharedObject.send command as appropriate. The SharedObject.send command broadcasts a message to all clients connected to a remote shared object, including the client that sent the message.