There is (as of Spring 2003) no way to "release" object replicas retrieved though CORK's ReplicatedObjectClient interface. Once retrieved, replicas remain in a client-side cache, and the server will send Change messages to the client for the duration of the client's connection. This approach has been reasonable for many CORK applications, but wastes both memory and bandwidth for long-lived applications or applications that involve briefly accessing many objects (such as MOO-ish tools).

A solution to this problem is also needed for server federation support (see Server federation), as caching servers will essentially act as long-lived clients. Finally, solving this problem will also allow us to re-design a more scalable indexing mechanism for search. (Since it is no longer practical for the indexer to hold all active objects in server-side memory.)

At the level of the interations between client and server, an additional message will need to be added that allows the client to tell the server that it is no longer interested in being notified of changes to the object with a given ObjectID. The initiation of this messaging is somewhat less straightforward. Possible solutions include:
  1. Use weak references in the client-side cache, and periodically check for objects that have been removed by the garbage collector. When such objects are found, release messages would be sent to the server.
    • Makes no assumptions about how applications manage attaching and detaching replication listeners.
    • but may make it impossible for heavily used objects to ever be released, since the processing of frequent remote changes may prevent the WeakRef'd object from actually being garbage collected.
  2. Allow ReplicationManager to initiate the release message when the number of stopSharing calls matches the number of startSharing calls.
    • Allows remotely active objects to be released when the local client is no longer using them.
    • but assumes application is using ReplicationManager (a generally safe assumption)
    • but will not handle the case where an object is retrieved and never modified

It does not appear that these two approaches conflict with each other, so it may be possible to do both. It probably makes more sense to do (2) first, since it will provide greater application control over release. Another hybrid approach would be to simply introduce a timer thread that would periodically release any objects that had been marked for release. This would introduce a window of time during which an object whose UI had been closed could be re-accessed without having to be re-retrieved.

All (?) ComponentViews currently extend bridge.DefaultComponentView, which invokes startSharing in the load() method. It does not invoke stopSharing, pending fixes to ReplicationManager's reference-counting implementation. Once those issues have been fixed, there are at least two places where we might want to turn off sharing:
  1. In deactivate() (note: this method may be renamed soon). This will be called when the object's UI is closed.
  2. In finalize(), which will be called at some point after the garbage collector has determined that the object can be freed.
Both have the disadvantage that they subclasses of DefaultComponentView must make sure they call their superclass's method if they override one of these. In practice, subclasses will rarely override finalize(), but will almost always override deactivate().

Timing is another issue: Releasing in deactivate will be immediate, while releasing in finalize will be delayed by an unknown time (and is, in fact, not garaunteed to happen at all). In the common case, the bandwidth and processing savings achieved by immediately releasing the object will make sense. In other applications, the user may be switching back and forth between objects, so delaying release will make more sense. Unfortunately this decision appears to be based on the nature of the application, and not on the nature of any individual component.


Notes:
  • Should ReplicatedObjectClient fire an event on object release?
  • For low-bandwidth connections, releasing large and/or infrequently changed objects immediately is problematic since re-accessing such an object will be expensive.

/public/projects/bridge/design/Releasing client-side replicas Login | Web Editor | Full Editor
Last modified 9/11/03 2:24 PM by isenhour (history)
Site contents