Electrical computers and digital processing systems: multicomput – Computer-to-computer data routing – Least weight routing
Reexamination Certificate
1998-03-20
2003-07-22
Courtenay, III, St. John (Department: 2126)
Electrical computers and digital processing systems: multicomput
Computer-to-computer data routing
Least weight routing
C709S241000, C709S241000, C709S241000, C709S217000
Reexamination Certificate
active
06598094
ABSTRACT:
BACKGROUND OF THE INVENTION
A. Field of the Invention
This invention generally relates to distributed systems and, more particularly, to a method and apparatus for determining a state of remote objects in a distributed system.
B. Description of the Related Art
Distributed systems typically comprise multiple machines, such as computers and related peripheral devices, connected in a network, for example, a Local Area Network (LAN), Wide Area Network (WAN), or the Internet. Distributed systems generally require that computational entities (e.g., applications, programs, applets, etc.) running in different address spaces, potentially on different machines, be able to communicate.
For a basic communication mechanism, distributed object-oriented systems utilize Remote Method Invocation (RMI), which is more generally known as Remote Procedure Call (RPC). RMI facilitates application-level communication between “objects” residing in different address spaces.
In object-oriented systems, a “class” provides a “template” for the creation of “objects” (which represent items or instances manipulated by the system) having characteristics of that class. The term “template” denotes that the objects (i.e., data items) in each class, share certain characteristics or attributes determined by the class. Objects are typically created dynamically during system operation. Methods associated with a class are generally invoked (i.e., caused to operate) on the objects of the same class.
RMI is the action of invoking a method of a remote object. In response to the invocation of a method on a remote object using RMI, a lower level communications process causes the invoked method to be executed on the remote object.
The Java™ runtime system, which is designed to implement applications written in the Java™ object-oriented programming language, supports a specific Java™ RMI Application Program Interface (API). This API is explained in, for example, a document entitled “Remote Method Invocation Specification,” Sun Microsystems, Inc. (1997), which is available via universal resource locator (URL) http://java.sun.com/products/jdk/1.1/docs/guide/rmi/spec/rmiTOC.doc.html, and is incorporated herein by reference. The Java language is described in many texts, including one that is entitled “The Java Language Specification” by James Gosling, Bill Joy, and Guy Steele, Addison-Wesley, 1996. Java and all Java-based trademarks are trademarks or registered trademarks of Sun Microsystems, Inc. in the United States and other countries.
Java RMI assumes a homogeneous environment of the Java runtime system, and therefore Java RMI takes advantage of the object model for the Java language whenever possible. In the Java™ distributed object model, a remote object is one whose methods can be invoked from another Java runtime system, potentially on a different machine. A remote object is defined by one or more remote interfaces written in the Java language that specify the methods of the remote object. For example, interfaces enable entities invoking methods on remote objects to define the methods supported by the remote objects without specifying the implementation of those methods.
“Garbage collection” is the term used in technical literature and the relevant arts to refer to a class of algorithms utilized to carry out storage management, specifically automatic memory reclamation. There are many known garbage collection algorithms, including reference counting, mark-sweep, and generational garbage collection algorithms. These, and other garbage collection techniques, are described in detail in a book entitled “Garbage Collection, Algorithms For Automatic Dynamic Memory Management” by Richard Jones and Raphael tins, John Wiley & Sons, 1996.
Distributed garbage collection extends the notion of garbage collection to the realm of distributed computing systems, reclaiming resources when no application on any computer in a distributed system refers to them. An automated distributed garbage collection process frees the programmer from determining when it is safe to delete a remote object. In the absence of a distributed garbage collector (DGC), a remote object would need to keep track of all clients that refer to the object and the object storage can be reclaimed when all clients no longer reference that object. For this function, Java RMI's DGC relies on a reference-counting garbage collection algorithm similar to Modula-3's Network Objects. See “Network Objects” by Birrell, Nelson, and Owicki, Digital Equipment Corporation Systems Research Center Technical Report 115, 1994.
To accomplish reference-counting garbage collection, the Java RMI runtime system, which is an implementation of Java RMI on top of the Java runtime system, keeps track of all remote objects referenced by computational entities (i.e., clients) executing through a local virtual machine (VM). The Java™ VM (JVM) is an abstract computing machine of the runtime system that receives instructions from programs in the form of bytecodes and that interprets these bytecodes by dynamically converting them into a form for execution, such as object code, and executing them. The JVM is described in detail in a text entitled “The Java Virtual Machine Specification”, by Tim Lindholm and Frank Yellin, Addison Wesley, 1996.
When a computational entity references a remote object, the local RMI runtime for the computational entity increments a corresponding reference count. Such a reference is typically referred to as a “strong” reference, and the computational entity is said to “hold” a strong reference to the remote object. A strong reference is one that will prevent the (remote) object from being collected. The first reference to a remote object causes the runtime system to send a “referenced” message to the RMI runtime for that object (e.g., another machine in the distributed system holding the referenced object). As remote objects are found to be unreferenced in the local VM, the local RMI runtime decrements the corresponding reference count.
When the local VM discards the last reference to a remote object, an “unreferenced” message is sent to the RMI runtime corresponding to that object. When a remote object is not referenced by any client, the RMI runtime system for the remote object refers to its “local” object (which was considered a remote object for the client) using a weak reference. The weak reference allows the remote object's garbage collector to discard the object, provided no other local “strong” references to the object exist. As in the normal object life-cycle, a finalization process is called after the garbage collector determines that no more strong references to the object exist. One type of finalization process causes the memory allocated for an object to be returned to a memory heap for reuse. As long as a local “strong” reference to a remote object exists, it cannot be reclaimed in this way by a garbage collector and it can be passed in remote calls or returned to clients. Passing a remote object adds the identifier for the VM to which it was passed to the referenced set. As a result of the “referenced” call from the receiving VM, the RMI runtime will keep a “strong” reference to the remote object to prevent collection.
A remote object needing “unreferenced” notification, i.e., a notification that no more clients hold references, must implement a special interface referred to as the “java.rmi.server.Unreferenced” interface. In this manner, when all references to the object from remote entities (e.g., former clients of the object) no longer exist, a method named “unreferenced” of the object will be invoked. The unreferenced method is called when the set of references for the object becomes empty.
Note that if a network partition exists between a client and a remote object, it is possible that premature collection of the remote object will occur since the transport might believe that the client crashed. Because of the possibility of premature collection, remote references cannot guarantee referential integrity; in other words, it is always possible
Jones Peter C.
Wollrath Ann M.
Bullock, Jr. Lewis A.
Courtenay III St. John
Finnegan Henderson Farabow Garrett & Dunner L.L.P.
Sun Microsystems Inc.
LandOfFree
Method and apparatus for determining status of remote... does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Method and apparatus for determining status of remote..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Method and apparatus for determining status of remote... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-3022810