You implement this design pattern in the client application, which creates a local language object, referred to in this chapter as the DataObject. The server application implements a CORBA process object that interacts with entities in persistent storage. This CORBA object is referred to in this chapter as the DataManager object.The OMG IDL for the DataManager CORBA object defines a data structure that is used for transferring data between the client and server applications. (This design pattern assumes "optimistic locking," meaning that the data managed by the server application is not locked for update, and that it is hoped that no other server processes modify the data while the client application uses its local copy.)When the client application instantiates the local DataObject, that object’s constructor invokes an operation on the DataManager CORBA object, which passes a data structure back to the DataObject. The DataObject populates its class variables with the passed data.If the client application needs to pass modified state back to the server machine, the client application invokes the DataObject::writeData() method, which, in turn, invokes the writeRecord() operation on the DataManager CORBA object. In this invocation, the data structure is passed as a parameter to the writeRecord() operation. The DataManager CORBA object makes the appropriate updates to durable storage.
1. The DataObject constructor invokes the readRecord() operation on the DataManager CORBA object, and uses the returned data structure to initialize its local state.
2. The client application may modify the local state of the DataObject instance.
3. To pass modified state back to the DataManager CORBA object, the client application invokes the DataObject::writeData() operation, passing a data structure containing the modified data.