Electrical computers and digital processing systems: memory – Storage accessing and control – Hierarchical memories
Reexamination Certificate
2001-12-06
2004-07-27
Gossage, Glenn (Department: 2186)
Electrical computers and digital processing systems: memory
Storage accessing and control
Hierarchical memories
C709S213000
Reexamination Certificate
active
06769048
ABSTRACT:
BACKGROUND OF THE INVENTION
Modem enterprise applications are typically implemented as multi-tier systems. Multi-tier systems serve the end-user through a chain of client/server pairs. Enterprise systems are typically implemented in a number of components, where each component may contain multiple object instances at runtime. The components are distributed across the client/server pairs. At runtime, each component interacts with other components in the system to provide a set of functions to the system.
FIG. 1
shows distributed components
2
,
4
in a client/server environment. The component
2
is the client, and the component
4
is the server. The client component
2
uses services from the server component
4
in order to provide functions to the system. In a four-tiered system, the client component
2
may be a web component hosted on a client
6
, and the server component
4
may be an application component hosted on a server
8
. The client component
2
may contain the logic required to display content on a web browser
10
. In order to generate content for the web browser
10
, the client component
2
typically needs to access enterprise data via the server
8
. Enterprise data may be held within a database
12
or within some other persistent data store. The database
12
is hosted on a database server
13
, which provides multiple management functions for the database
12
, such as regulating access to the data contained within the database
12
. These functions are carried out by database objects
17
located inside database components
15
that are located on the database server
13
. The client component
2
interacts with the enterprise data in the database
12
through the server component
4
. In a three-tiered system, the application server
8
would typically be absent, and the client component
2
interacts with the database
12
directly through the database server
13
.
At runtime, the server component
4
includes one or more objects
14
, which may be persistent objects that model data within the database
12
or transient objects that can perform operations such as reading or writing from the database
12
or executing business logic. At runtime, the client component
2
and the server component
4
belong to different address spaces, which may be in the same machine or in different machines connected by a network link, such as network link
16
. Before the client component
2
can invoke a method of a server object
14
, the server object
14
must exist in the server component
4
. If the server object
14
is not already in the server component
4
, the client component
2
needs to call on other objects already in the server component
4
to instantiate the server object
14
. Typically, the client component
2
calls on an object factory
18
that knows how to instantiate the server object
14
. Once the server object
14
is instantiated or is found, the client component
2
can invoke a method of the server object
14
by sending a message to the server object
14
. Typically, the client component
2
locates the server object
14
through an object location service
20
that keeps track of the location of all distributed objects in the system. The server object
14
executes the operation requested by the client component
2
and returns the result to the client component
2
.
When objects are used in a distributed environment, such as that described above, it is often desirable to maintain a cache of objects close to where the objects are accessed most frequently. For example, in the environment illustrated in
FIG. 1
, it may be desirable to cache objects on the client
6
, remote from the application server
8
and the database
12
where the state of the objects is ultimately stored. The reasons for caching the objects on the client
6
are to decrease network latency, reduce bandwidth demand, and improve client availability. The client cache
38
in
FIG. 1
acts as an intermediary system that intercepts requests for access to the database
12
(via the application server
8
in the case of a four-tiered application). The client checks if the requested object is available in its local storage, i.e., client cache
38
. If available, a reference to the requested object is sent back to the requesting program, e.g., the client component
2
. Otherwise, the client cache
38
forwards the request to another cache or the database management system (DBMS) to retrieve the requested object from the database
12
. When the client cache
38
receives the requested object, the client cache
38
keeps a copy of the object in its local storage and forwards a reference to the object to the requesting program.
In a distributed environment, there may be multiple client processes requesting access to objects stored in a database. Each process may include a client cache for storing a local copy of objects retrieved from the database. When an object is represented in more than one client cache, or when the database representation of the object can be updated by means other than the object, a cache coherency problem may arise, whereby the objects stored in the caches become inconsistent with each other and/or with the underlying database copy. In this case, programs that use the cached objects may produce incorrect results based on “stale” data. Therefore, maintaining coherency between distributed caches and the database is important.
Most object-oriented database products and object-relational mapping systems maintain caches of some kind. Some of these systems also provide mechanisms for maintaining distributed objects. Various work has been done on synchronizing caches in database systems by sending events or messages from the DBMS to the distributed clients. This strategy can be effective if it is handcrafted, but tends to flood the network with updates if used indiscriminately. Further, database transactions provide a mechanism for ensuring that serializability between concurrently running applications is reliably detected. However, for applications that have high transaction rates (such as web applications), it is not practical to enforce strict serializable transactions. Instead, applications are typically hand-tailored to prevent critical collisions and to allow other collisions that may not matter.
The objects derived from a database are typically used by multiple applications, and prior-art cache consistency is typically keyed to the object schemas. For a given application, the result is either a schema that is too strict, limiting the ability to scale the application, or a schema that is too lenient, allowing collisions that would produce incorrect results. For example, consider a set of objects representing a purchase order, including a reference to an item being sold and the customer making the order. If the item becomes out of stock while the purchase is being made, the customer should be made aware of the change prior to committing the order. However, if the item becomes out of stock while a report of the customer's yearly purchases is being generated, the change in status of the item may not matter. In general, the difference depends on the application's use of the objects, not on inherent characteristics of the objects.
SUMMARY OF THE INVENTION
A cache synchronization method for a distributed application having a client side and a server side, comprises detecting initiation of a transition to a new state on the client side, locating data on the client side that is to be synchronized, synchronizing located data using a cache synchronizer interposed between the client side and the server side, and completing the transition to the new state on the client side.
A cache synchronization method for a distributed application having a client side and a server side, comprises detecting initiation of a transition to a new state on the client side, locating data on the client side that is to be synchronized, synchronizing located data using a cache synchronizer interposed between the client side and the server side, completing the transition t
Ali Syed M.
Daniels Bruce K.
Goldberg Robert N.
Kamen Yury
Yared Peter A.
Gossage Glenn
Osha & May L.L.P.
Sun Microsystems Inc.
LandOfFree
Cache synchronization method, system and apparatus for a... does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Cache synchronization method, system and apparatus for a..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Cache synchronization method, system and apparatus for a... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-3239320