Macromedia flash media server 2-developing media applications User Manual

Page of 114
The SharedObject class
53
On the other hand, if your application needs to send only information that has changed, then 
you should divide the data among multiple slots. This implementation reduces network 
traffic and thus enhances the performance of your application. It also minimizes the need for 
conflict resolution code, as multiple slots can be updated simultaneously without data 
collision.
Flushing remote shared objects
Flash Media Server automatically flushes remote shared objects to the disk, on both the client 
and the server, when all users disconnect from the shared object or when the server shuts 
down. At any other time, if you want the shared object to be updated on disk, you must call 
the client-side 
SharedObject.flush()
 method. 
However, calling 
SharedObject.flush()
 in the client-side ActionScript flushes only the 
local copy of the shared object. To manually flush the server copy of the shared object, you 
must call 
SharedObject.flush()
 in a server-side script, as follows:
// Sample server-side code for flushing a persistent shared object 
// to the server
// Get the shared object when the application is loaded.
application.onAppStart = function()
{
application.mySO = SharedObject.get("SharedObjName", true);
}
// When a user disconnects, flush the shared object.
application.onDisconnect = function(client)
{
application.mySO.flush();
}
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. The 
following examples describe a few strategies:
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.