HOME | SITE MAP | SEARCH | CONTACT | GLOSSARY | PDF FILES | WHAT'S NEW
GETTING STARTED | TABLE OF CONTENTS | PREVIOUS TOPIC
|
|
|
BEA WebLogic Enterprise 4.2 Developer Center |
|
HOME | SITE MAP | SEARCH | CONTACT | GLOSSARY | PDF FILES | WHAT'S NEW |
||
|
GETTING STARTED | TABLE OF CONTENTS | PREVIOUS TOPIC |
||
This chapter describes the Client Data Caching design pattern. The purpose of this design pattern is to make persistent state information from the server available locally to the client for data-intensive processing. This way, the client application does not need to make repeated invocations to the server application to retrieve data.
This design pattern addresses the scalability and performance of distributed client/server applications. The overhead associated with remote invocations to retrieve attributes of a CORBA object may be quite high, depending on system load and other factors. Also, exposing persistent data records as CORBA objects tends to create applications that do not scale well because of the potentially large number of simultaneously active objects that must be managed by the system. Client application processing that is either data-intensive or that requires user input (for example, editing fields) can slow down both the client application and the system if multiple remote invocations must be made to retrieve data.
This design pattern is appropriate in situations where the CORBA process object needs to pass a large amount of data to the client application for its use. The local language object on the client application becomes a container for the data, and its constructor is used to populate the local object state.
You implement this design pattern in the client application, which creates a local language object, referred to in this chapter as the The OMG IDL for the When the client application instantiates the local If the client application needs to pass modified state back to the server machine, the client application invokes the The following figure illustrates how the Client Data Caching design pattern works.
In the preceding figure:
Motivation
Applicability
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.
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.)
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.
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.
DataObject constructor invokes the readRecord() operation on the
DataManager CORBA object, and uses the returned data structure to initialize its
local state.
DataObject instance.
The DataObject methods read and write data by invoking operations on the DataManager CORBA object.
The data structure passed to the client application should be designed to provide the minimal set of data required for an operation. If a large amount of data is involved, it may be more efficient to provide multiple data structures with a subset of fields required for each operation. Operations on the CORBA process object should be designed to involve only the subset of data needed for each operation; this helps reduce network traffic.
