Table of Contents
Advertisement
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()
However, calling
SharedObject.flush()
local copy of the shared object. To manually flush the server copy of the shared object, you
must call
SharedObject.flush()
// 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
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.
method.
in a server-side script, as follows:
The simplest strategy is to use a different slot for each user that might
in the client-side ActionScript flushes only the
The SharedObject class
53
Advertisement
Table of Contents
