Electrical computers and digital processing systems: multicomput – Computer-to-computer data routing – Least weight routing
Reexamination Certificate
1997-02-04
2001-01-23
Oberley, Alvin E. (Department: 2755)
Electrical computers and digital processing systems: multicomput
Computer-to-computer data routing
Least weight routing
C709S241000
Reexamination Certificate
active
06178463
ABSTRACT:
TECHNICAL FIELD OF THE INVENTION
The present invention relates to object-oriented data processing systems with transactional properties.
BACKGROUND OF THE INVENTION
Object-oriented (OO) computing is now a well-established computer programming technique offering high productivity and reliability to the application program developer. An “object” is a self-contained software package which combines “variables” and “operations” (also known as “methods” ) which operate on these variables. Variables may take data values so that an object's “state” is defined by the values of its variables at any point in time. Operations are the only way of accessing an object's variables for the purpose of reading or modifying them. In addition to having an effect on its local state, an operation can itself cause “messages” to be sent to other objects which causes invocation of further operations at recipient objects.
An object is defined via its “class” and is an “instance” of the class. A class is a software template that defines the external interface of the object by means of interface definition language (IDL) statements. The external interface is unchanging and enables the object's operations to be invoked and data to be passed to and from the object variables. The internal implementation of an object may be changed providing its external interface conforms to its class definition. Because of the continuity of the external interface, objects are readily reusable by other application programs and also may be replaced by freshly written versions without affecting an application program which invokes them.
Other important aspects of object-oriented programming such as “inheritance” (the ability to have an object subclass which inherits the methods and variables of a superclass) and “polymorphism” (the property that objects in different classes may respond to the same message) are not strictly relevant to an understanding of the present invention. A more general description of object-oriented technology may be found in “SOM objects: A Practical Introduction to SOM and DSOM” (Document No. GG24-4357-00, July 1994, IBM Corporation).
Object-oriented programming techniques have now been applied to many applications. One of the best known of these is data base management. Object-oriented data base management systems (OODBMS) are now well established in the marketplace. With any data-base management system, whether object-oriented or not, the problem of concurrency control (or serializability) is well understood. This is essentially that inconsistent changes to the data base may occur and erroneous information may be read or stored if access to the data base records for the purpose of reading or writing data is not strictly controlled and sequenced. This problem of maintaining data base integrity is normally tackled by imposing transaction processing techniques on the data base operations together with a lock management system.
Transaction processing is a long established programming technique in which a sequence of associated operations which transforms a consistent state of a recoverable resource into another consistent state forms a “transaction” (sometimes referred to as a “unit of work”). A transaction must either be “committed” on completion, in which case all changes required by operations are made permanent, or “aborted”, in which case all changes actually made by the operations are rolled back (undone). In the transaction processing context, this is known as “synchronization” or “coordination”. A general discussion of transaction processing can be found in “Transaction Processing: Concepts and Products” (Document No GC33-0754-00, IBM Corporation).
By applying transaction processing principles to data base access operations, integrity of the data can be assured even in a large distributed system.
Many of the concurrency considerations for applying transactional techniques to data bases are also relevant in considering object-oriented systems in general (not only OODBMS). In the same way that operations on databases are transactional, it is now recognised that operations on objects need to be transactional to conserve application data integrity and consistency.
As pointed out by T. and V. Hadzilacos in an article “Transaction Synchronisation in Object Bases” (J. of Computer and System Sciences 43, 1991 pp 2-24), concurrency control considerations in so-called object bases differ in some respects from data base concurrency control. One of the differences is that operations in a general object setting may be nested in that a user application invokes operations which may invoke other operations and so on. This is unlike the traditional data base setting where transactions issue a sequence of simple read and write actions. A second difference is that general object transactions can be implemented as quite long running programs and thus cannot efficiently be processed serially like the shorter read and write operations in data bases. It is therefore necessary to provide for multiple invocations of operations of the same object to be active simultaneously, rather than being mutually exclusive. Such simultaneous executions must be synchronised since they may share access to common variables of the object. Finally, to further assist parallelism, operations in general object systems should exhibit internal concurrency, in order that they can send messages, invoking operations on other objects simultaneously.
The article proposes a conceptual scheme for achieving this level of concurrency control by separating the task into intra-object and inter-object synchronisation and proposing a formal model for execution in an object system.
Another article “An overview of the Arjuna distributed programming system” (S. K. Shrivastava et al, IEEE Software, January 1991, pp 66-72 describes a prototype object-oriented programming system for a distributed system. The Arjuna system offers concurrency control and recovery by implementing nested atomic actions (transactions) on persistent objects. By using type inheritance, objects may control their own level of concurrency in a type-specific manner. An object becomes active when an operation is invoked on it by a transaction and remains active until the transaction commits or aborts. If the transaction is nested inside other atomic actions, the object will remain active until either the outermost transaction commits or the invoking transaction or an ancestor transaction aborts. The implementation of Arjuna defines a base class State Manager which enables the construction of persistent objects and atomic actions (transactions). This supports object activation, deactivation and recovery. A Lock Manager uses these facilities and provides concurrency control (implemented as two-phase locking) to implement what is referred to as atomic-action serializability. Transactional behaviour is not imposed by the system on all operations on objects, however, but is initiated in response to the user's class definition declaring atomic actions to control the recovery requirements of the class.
European patent application no. 0613083 A2 entitled ‘Transaction Management in object oriented systems’ also describes a system in which user generated client applications may impose transactional constraints on operations they start by issuing a create-transaction call to a Transaction Manager. The Transaction manager returns a transaction identifier which the client then passes to an Object Manager (server) which, in turn, indicates to the Transaction Manager that it has joined the transaction. The purpose is to allow clients to customize their own transaction requirements without requiring the operating system kernel to provide transaction management. Provision is also made for nested transactions.
Although providing for transactional behaviour in object-oriented systems, neither the above referenced European patent nor the Shrivastava article address the requirement described in the Hadzilacos article, to assure complete concurrency control of all operations in an object-ori
Houston Iain Stuart Caldwell
Josephs Mark Brian
Courtenay, II St. John
Gates & Cooper
International Business Machines - Corporation
Oberley Alvin E.
LandOfFree
Object-oriented data processing system with transactional... does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Object-oriented data processing system with transactional..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Object-oriented data processing system with transactional... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-2476926