Object Synchronizer: A Design Pattern for Object Synchronization Ant´ onio Rito Silva , Jo˜ ao Pereira and Jos´ e Alves Marques INESC/IST Technical University of Lisbon, Rua Alves Redol n 9, 1000 Lisboa, PORTUGAL INRIA, Domaine de Voluceau, Rocquencourt, B.P. 105, 78153 Le Chesnay Cedex, FRANCE Rito.Silva@acm.org, Joao.Pereira@inria.fr, jam@inesc.pt This pattern was workshopped at the European Con- ference of Pattern Languages of Programs (EuroPLoP96), Kloster Irsee, Germany, July, 1996. Abstract This paper describes the Object Synchronizer pattern which decouples object synchronization from object func- tionality. This pattern supports several synchronization policies and their customization. This pattern is used when invocations to an object need to be controlled in order to preserve its consistency. The solution described by this pat- tern provides encapsulation, modularity, extensibility and reuse of synchronization policies. 1. Intent The Object Synchronizer pattern abstracts several object synchronization policies. It decouples object synchroniza- tion from object functionality. 2. Also Known As Object Concurrency Control. Object Serialization. 3. Motivation 3.1. Example Consider the design of a Cooperative Drawing Applica- tion allowing cooperative manipulation of graphical docu- ments. Users at different terminals can simultaneously ac- cess the same graphical document and changes made to a local view are immediately propagated to other local views. Due to the cooperative characteristics of the application a shape can be made private, publicly readable or publicly writable. A shape is private when it is only visible to the user that has created it: its owner. A shape is publicly read- able when it is visible to all users but only its owner can update it. A shape is publicly writable when any user can see and modify it. A possible architecture for such an application contains several client applications having their own objects (ap- plication space) and sharing a set of domain objects (do- main space) which may be kept in a data store (persistent space). The application space has interface objects, e.g scrollbars and shapes; the domain space has shared objects, e.g. shapes data; and the persistent space stores documents, e.g. a graphical document including its shapes’ data. 3.2. Problem Client applications execute operations that invoke meth- ods on shape objects. Invocations on a non-private shape object must be controlled either because it is a publicly readable shape where update invocations from non-owners should return an error; or because it is a publicly writable shape where simultaneous invocations by different client applications are liable to result in corruption of the shared shape’s state. Traditional solutions for object synchronization use: The persistent space’s locking mechanisms to syn- chronize invocations to shared resources. However, a shared object may just be volatile and the effort to make it persistent may result in unacceptable over- head. Another issue is that the supported locking mechanisms may not be suitable for the synchroniza- tion needs of the application. Synchronization mechanisms, as semaphores [1] and monitors [2], to synchronize accesses. However, this results in code tangling which forbids, both function- ality and synchronization independent reuse. For in- stance, a shape’s functionality code should be the 1