WO2000065458A1 - Method and apparatus for maintaining data integrity across distributed computer systems - Google Patents
Method and apparatus for maintaining data integrity across distributed computer systems Download PDFInfo
- Publication number
- WO2000065458A1 WO2000065458A1 PCT/US2000/011554 US0011554W WO0065458A1 WO 2000065458 A1 WO2000065458 A1 WO 2000065458A1 US 0011554 W US0011554 W US 0011554W WO 0065458 A1 WO0065458 A1 WO 0065458A1
- Authority
- WO
- WIPO (PCT)
- Prior art keywords
- application
- database
- server
- server application
- cache
- Prior art date
Links
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
- G06F16/23—Updating
- G06F16/2308—Concurrency control
- G06F16/2315—Optimistic concurrency control
- G06F16/2329—Optimistic concurrency control using versioning
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/02—Protocols based on web technology, e.g. hypertext transfer protocol [HTTP]
- H04L67/025—Protocols based on web technology, e.g. hypertext transfer protocol [HTTP] for remote control or remote monitoring of applications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
- G06F16/23—Updating
- G06F16/2365—Ensuring data consistency and integrity
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
- G06F16/23—Updating
- G06F16/2308—Concurrency control
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/54—Interprogram communication
- G06F9/547—Remote procedure calls [RPC]; Web services
Definitions
- Remote Procedure Call systems permit a program running on one computer to invoke a function on another computer.
- Object Request Brokers provide a similar service, but with some minor variations that follow the conventions of object technology.
- Database access systems let a program retrieve data from a database on another computer.
- Messaging systems let one program communicate with another on a remote computer, sometimes storing the message if necessary and forwarding it when communication can be established.
- Publish and subscribe systems permit one program to broadcast a message, and only those systems that have subscribed to that message receive it.
- the communications technology provides the same services when communicating with another program on the same computer, or one on another computer; in some cases, even when communicating with a service within the same program.
- different techniques must be used when communicating in the different configurations.
- No existing service meets all of the requirements of modern distributed applications.
- the different services are rarely integrated, which means that a program that needs some combination of services has to do a lot of work to combine them. In practice, it is very difficult to do this, without introducing subtle errors that undermine the integrity of the data.
- the closed nature of many of these services often make it impractical for a developer to combine them. For example,
- Microsoft Co ⁇ oration provides an ORB service called COM that is based on conventional, connection-based communication.
- Microsoft also provides a store-and-forward messaging system called MSMQ.
- MSMQ store-and-forward messaging system
- COM does not support the use of MSMQ for communication, to permit asynchronous invocation of services.
- the object server can expose the properties individually, using property retrieval methods of the type getCurrentBalance and property setting methods like setCurrentBalance. But this can be very inefficient: to retrieve a complete picture of an object's state, the client program would have to make a large number of requests. Modern network systems and database management systems are not designed to handle large numbers of small requests very efficiently: the overhead and latency of both networks and databases would make this very costly.
- the object server can expose a getState method that returns a data structure that contains the entire state. This is more efficient, since the entire state is shipped to the client in one conversation, but it breaks the object model.
- the state is encoded as a typical struct of common non-object languages, we have a breakdown of the programming model, intermixing object and non-object technology. If the state is encoded as an object, we have two different types of objects with very different characteristics: the state is a local, client-side object with no methods and no relationship with the server; the original service is an object with methods but no properties. To change the properties of the server object, the application has to make the changes to the local state object and then ship it back to the server by invoking a method like setState(theState). While the technique certainly works, it is not a clean or easily maintained programming model.
- Some of these systems include automatic cache management. When a record has been retrieved from the server, the application can retrieve values from the record again without requiring a re-fetch, and changes to the records are maintained in the cache and written back to the server all at once when a Commit operation is executed. Some such systems are based on object technology, in that they present the retrieved data in the form of objects in the application's programming language.
- Such systems have a serious limitation in that they retrieve the objects to the client, but they cannot then invoke methods of the object on the server. Invoking methods of an object on the server would raise a difficulty for such systems once the object's state has been shipped to the client, that's where the object is maintained, its state may be modified on the client, and executing methods on the server may not be meaningful.
- Cache management is a well-known technology: many systems, from database access tools to Web browsers, provide local caching of information to improve response time and reduce network traffic .
- a read cache is used to keep copies of information that has been retrieved: if the application requests the same information again, it may be fetched from the cache.
- the cache may be transient, with information surviving only during the session, or it may be persistent, keeping information on disk between sessions or even when the computer is turned off.
- the cache may become stale. In some situations, such as web browsers, such staleness is acceptable, and responsibility for updating the information from the server rests on the user. In other cases, this is not acceptable, either because the information is more dynamic or because the application is more important.
- Asynchronous event notification of server-side changes is a proven technique for maintaining synchronicity among the elements of a distributed application.
- An application program can work with objects persistently stored in a database, and use caching for its well-known performance benefits. If another application elsewhere in the network changes a value of an object in the database, the system will send an event notification to the application, updating the value of the object. The value is updated in the cache, and an event notification is sent to the application so it can update the value in its calculation or on-screen.
- a write cache is used to temporarily hold changes made to the data.
- a client-side application makes changes to objects in its cache, those changes are held in the client-side write cache.
- the changes are written through to the database server.
- the changes are written through when a Commit operation is done in the application.
- changes may be written through earlier, but at a minimum the write-through is completed at the Commit time.
- the application is essentially stopped during this wait; with an uncompleted transaction pending, no other database operations can be done because they would become part of the same transaction, which violates the semantics of the application.
- the systems may be disconnected for a number of reasons. There may be unplanned outages: network links may go down temporarily due to hardware or software failures, congestion or radio link interference. Such unplanned outages are more common today than in the past, because more systems operate in widely distributed configurations, communicating over unreliable dial-up or wireless links. There may also be planned outages: a laptop computer, for example, may be only intermittently connected, with a sales representative using the machine to quote prices to prospective clients, and only occasionally connecting to headquarters to download price changes.
- pessimistic concurrency control is not practical in a far-flung distributed environment, certainly not in one with intermittent connection.
- An organization cannot permit traveling salesmen to hold locks on objects in a database in headquarters-that would for example, prevent headquarters from changing prices.
- the only practical concurrency control model in such widely distributed environments is optimistic, in which remote applications do not hold locks in the database and instead rely on event notification.
- an application may keep track of the archival status of files on a disk, and the method invoked may be a backup job; after the completion of the backup job, the modified archival status flags should be sent to the application, and this may need to be queued since there is no need to interrupt the backup job just because a network link is temporarily interrupted.
- Store-and-forward is another well-known technique, where messages that are sent to a computer location are stored in a queue temporarily if the destination computer is not available, and delivered as soon as a connection can be established.
- object databases operate under a convention that when an object of a potentially persistent class is created in an application, it is still transient. The object becomes persistent only when explicitly saved through the execution of some specific method or statement.
- objects may also have references to one another. These references may be direct, so that an object has a property that contains a direct pointer or an address or path to another object. Alternatively, they may be indirect, so there is a third object that acts as the association or link between the two objects.
- Such systems have at least one potential problem: a persistent object may have a dangling reference, a pointer to an object that was never saved and therefore does not exist when an application tries to recreate the object structure.
- the program has two copies of the original property. Let's say that the original value was 1000, for example. The third statement of the program would make the property 1100. The fourth statement would make the property 1200. The fifth statement would write 1100 to the database. The last statement would write 1200 to the database. In effect, the addition of 100 has been lost.
- transaction management or concurrency control does not solve this problem, since the error occurs even when all these operations occur within the same transaction context. Concurrency control prevents separate programs from interfering, but it does not eliminate the possibility of errors in programming logic.
- Optimistic transactions consist of two distinct phases: a long-running read phase followed by a short write phase, also known as the commit phase.
- a long-running read phase During the read phase, objects are retrieved without locking and placed into the private transaction cache where they can be modified without affecting other transactions. Objects are written back to the shared store during the commit phase.
- an optimistic transaction relies on the assumption that no other transaction has modified the objects while it was running. This assumption is validated before changes made by the transaction are saved in the database. It is believed that optimistic concurrency control outperforms other methods in systems with low to moderate contention. The majority of today's e-commerce applications fit this profile.
- the web server and the application server processes are in the center of the star. They are connected to a number of web browsers and to several information providers.
- the application server is responsible for bringing data from the information providers to the web server clients. Data caching and optimistic transaction processing is also done in the middle tier where the application server is located.
- This architecture is suitable for applications that have only web-based, or "thin", clients and for the ones that access only a limited number of back end information providers.
- it is not optimal for applications with a mixture of both "thin” and “fat” clients.
- a "fat” client would need to access data residing in the cache of a remote application server, not much of an improvement compared to the traditional client/server architecture.
- bringing raw data from a large number of information providers to a single central location may have negative scalability implications when the data needs to be modified before it can be made available to the clients.
- Figure 1 shows a network having a star architecture consistent with certain prior art networks.
- Figure 2 shows a network having a distributed architecture consistent with the present invention. 6. Detailed Description
- Applicants' system combines several known technologies in new ways, and adds new technologies, to address these problems of existing systems.
- Applicants' system addresses several specific problems, each through a particular combination of technologies.
- the system further also uniquely combines these services to provide a single infrastructure that supports service providers (methods without persistent storage), in addition to classical databases
- a "provider” which is a software system that provides information or services.
- the specification refer to an "information provider”, a provider whose main function is the delivery of information, or to a “service provider”, a provider whose main function is delivering a processing service of some sort.
- Information providers include classical, relational and object databases, directories, file systems, monitoring agents, the Internet, and other programs that provide data.
- Service providers include business applications, management tools, backup agents, and other programs.
- a "consumer” is a program that retrieves data, makes changes to data, stores data or invokes services.
- a consumer may be an application program of some sort, or a simple interactive tool such as a browser that allows a human being to interact with the information or services.
- a single software component may be both a consumer and a provider at the same time.
- a provider may respond to requests, but in meeting those requests may act as a consumer, requesting other services from other providers.
- a provider may send event notifications or other messages to a consumer, or to other providers.
- the system provides services that allow software and hardware systems to communicate, whether they are located in the same process on one computer, in different processes on one computer, or on different computers; whether they act as consumers or providers, of information or services; whether they send or respond to requests, or send or react to events.
- State Shipping combined with Remote Function Invocation
- Applicants' system combines state shipping with remote method invocation.
- an object When an object is accessed, its state is shipped to the client and stored in the client-side cache, in the manner of present-art database access systems. This combination is accomplished under a rigorous object model, and the objects are exposed to the application as native objects in the application language, through a language binding.
- the state of the objects may be accessed directly, and these accesses are resolved locally from the cache.
- the state may be updated directly, and these changes are held locally in the cache, and written back to the server later under a lazy-write algorithm.
- the lazy-write algorithm may decide to do the write-through at various times, depending on the concurrency control model used and on optimization decisions, but at the very latest it is written when a Commit operation is invoked.
- Server-side methods are exposed through this language binding in the form of standard methods of the application programming language.
- the state should be synchronized between the client and server or other affected computers.
- the cache manager writes through to the server all changes made to the state of the objects in the client application before the server-side method is actually invoked.
- synchronization is not necessary when executing client-side methods. It is possible to modify the logic of the state synchronization service of Applicants' system to optimize the amount of information written through. Some of the state changes may not be relevant to the method, and hence would not need to be written through at this time.
- the state synchronization service cannot determine this, since the methods may be implemented in a multitude of languages and may be arbitrarily complex; therefore, to be on the safe side, it should write through all property changes. Of course, such manual control would be a possible variation of Applicants' system.
- the server-side method After the server-side method has been invoked, there may be a need to synchronize the client-side cache with the database.
- the method may have had side effects, modifying the state of the object it belongs to, or that of other objects that are also in the client's cache. Therefore, after a method invocation, the state synchronization service automatically synchronizes all objects in the cache that have been modified in the server.
- the transaction management services can switch over to pessimistic concurrency control when the method is invoked. These execution options may be selected as part of the configuration settings of the system.
- Applicants' system uniquely combines these two capabilities, cache management and store and forward.
- store-and-forward messaging feeding the cache management system all notifications of server-side changes that occur during an outage are stored in a queue, and as soon as the connection is reestablished the changes are propagated and reflected in the cache and the application.
- An advantage of the integration of the present invention is that the application need not be aware of the intermittent synchronization process.
- the application may be written as if it had continuous and reliable access to the database, with the language bindings providing immediate access to a vast pool of objects.
- the cache improves the performance of the application, the store-and-forward queuing ensures that all changes are propagated to the application, all without any change in the style of programming in the application.
- Resilience To Unplanned Outages This integration of store-and-forward queuing with cache management increases the resilience of the entire system to short-term unplanned outages. Such an unplanned outage may be very short, especially with dial-up or wireless linkages. For example, a cellphone connection may be lost while a vehicle travels under a bridge, and re-established within seconds or minutes. The application and cache manager may continue to run during this outage. Yet, notifications from the server may be lost.
- persisting the cache is the responsibility of the cache manager. In others cases, for example when operating on a laptop, it is the responsibility of the operating system.
- Applicants' system may be contrasted with replicated database which can be configured to provide some similar benefits.
- Database replication schemes however, rely on database homogeneity, which means that an identical, or at least structurally and semantically similar, database be available at every node. On small computers, such as laptops or palmtops, this is not practical. In any case, Applicants' system provides these benefits with merely a persistent or non-persistent cache, which is a much useless burdensome technology than a database. Persistence by Reachability
- Applicants' system extends the concept of persistence through reachability across several information providers. Whenever the infrastructure decides that an object needs to be persisted, through the persistence-through-reachability algorithm or because the application program explicitly requested it to be persisted, it determines to which database provider the object is to be persisted. This may be determined through any one of a number of techniques, including for example:
- the class that the object belongs to may be associated with a schema defined in a particular database, and the object is to be stored in the same database •
- the class that the object belongs to may have a particular database store specified, regardless of where the schema came from
- the system may decide which store to use based on some criteria of its own In these cases, the two objects that have a reachability relationship may be persisted to different databases. The relationship between them may be implemented through a reference that can accommodate different stores.
- the persistence by reachability algorithm relates in substantially the same way regardless of where the objects are to be stored. As long as the objects are held in the cache memory or in the application program's own memory, the relationships between the objects are known to the persistence infrastructure.
- the persistence by reachability aspect of Applicants' system navigates these references and makes its determinations which objects should be persisted in the conventional manner, by identifying all objects that are reachable from each persistent object, and marking them to be persisted. It then uses one of the techniques listed above to determine to which database the object should be persisted, and then effects the persistence in a conventional manner. Duplicate Object Resolution
- Applicants' system solves the problem of duplicate object resolution by automatically detecting when an operation would retrieve from the database an object that has already been activated or fetched from the server to the client. Since the system maintains in its cache all the objects that have been activated, whenever an object is fetched the system determines if the newly fetched object would duplicate an existing object in the cache, and if so, discards the new copy and instead uses the existing copy in the cache.
- This technique applies whether the object is fetched from the database directly, by name; by following an inter-object relationship, an association or pointer from one object to another; by executing a query that returns a number of objects that match some specified criteria; by lookup in a list of recently visited objects; or by any other technique. How the object is arrived at does not matter; when it arrives, the system detects that it is a duplicate and discards the new copy.
- Performance Improvement Variations Of course, in many cases the system can detect that an object to be fetched already exists in the cache and eliminate the request to the database server altogether, thus reducing network traffic and database load, and improving response time. In other cases, such as when executing a query, utilizing the database cannot be avoided. In any case, these variations only affect performance, and do not alter the fundamental operation of the system. Distributed Methods
- An object database stores objects, and those objects have both properties and methods.
- the schema defines which methods exist for a given class of object.
- the methods are implemented in the same object database.
- the definition of the method simply give its name and the class to which it belongs, and no further location specification is required since its location is implicit in the location of the object.
- the database may be less than completely capable. For example, if objects are stored in a relational database, the ability to execute methods may be limited. In such a case, the methods may be implemented as separate programs, perhaps executing on the same machine where the database is, perhaps executing on another one.
- the objects that are stored in the database may represent physical pieces of equipment or software elsewhere in the system.
- Such an object,-a router, for example- may have capabilities implemented as programs that operate in the object itself; management services may provide functions that are implemented elsewhere; and the application may provide some functions that involve a graphical user interface and hence operate on the user's workstation. In all these cases, these services may be viewed as methods of the object, even though they may be implemented all over the network.
- the methods of a class may be implemented in legacy programs or third-party programs over which the developer has little control.
- the methods may be implemented in different programming languages, databases or operating systems. Nonetheless, in order to simplify the use of these methods in application development, it is desirable to present these various methods as parts of one cohesive whole. It is of course possible to build a piece of software that ties together these separate method implementations, but building such a connecting service is a lot of work, and any change in configuration requires changes to the code. It is desirable to define and maintain the relationships externally, through administration of schemas, regardless of type and location of the methods.
- Applicants' system permits the schema to include definitions of methods that specify the location of the method, not just its name.
- the system permits an application to access an object in the database, and simply invoke a method on that object as if it were a standard, built-in method; the system will take care of dispatching the method invocation request to the appropriate location.
- the definition of a method should also specify how the method is implemented. It may be for example, a C or C++ DLL, invoked with a normal subroutine call. It may be a Java program, an executable program, or even a BAT file.
- the schema identifies which technology is used, and how the method should be invoked.
- the method should also specify how the object is identified.
- a method is implemented as an external program, it of course does not have the context of the original object.
- the method schema specifies how the invocation is to be done, in such a way that the context can be preserved.
- Class and Instance Level Methods The technique for handling external implementations of methods works equally well for instance-level methods that are attached to an object as for class-level methods that are attached to the class.
- the identity of the originating object is passed in to the method. The way this is done for example, the identify could be passed is specified in the schema, as part of the method definition as an argument in the call, as a command line parameter when launching an executable, or whatever is appropriate in the specific configuration.
- a system that combines remote method invocation with state shipping should take care of synchronizing the state between the client and the server before and after a method execution.
- this state synchronization should include the computer on which the method is to be executed.
- the state may be synchronized to the database that serves as the persistent store of the object.
- the method can then retrieve the state from the database before executing.
- the system writes any persistent state changes to the database.
- the client-side cache manager is notified of these state changes and uses them as the basis for post-method state synchronization. Note that if the method is running on a computer that already has a copy of the object in its cache, it may not need to fetch the object from the database.
- the state may be synchronized to the cache of the server that is to execute the method.
- Applicants' system employs a unique dynamic concurrency control mechanism that is based on a combination of locking (pessimistic) and non-locking (optimistic) concurrency control strategies.
- Each instance of the runtime system contains its own object cache and its own transaction manager. It may be run on a client machine where it can provide local data access for non-web based applications.
- Several instances of the runtime can be grouped together in the middle tier. There they can be accessed by the web clients and by other runtime instances. Automatic load balancing ensures improved scalability.
- a separate runtime instance can be placed close to a legacy database and used to perform object-to-relational mapping. Objects are delivered to the middle tier in an assembled form, which reduces the number of network messages required to access the objects.
- the architecture successfully resolves many non-trivial issues associated with transparent information access in a distributed environment.
- An optimistic transaction may access data via a number of instances of the runtime system. For example, a transaction started by the application "Appl” shown in Figure 2 passes through at least three runtime instances when accessing data in the information provider "DB1".
- each of the runtime instances maintains the read and the write sets of the transaction.
- its read set is compared with the write sets of transactions that have already committed.
- the transaction is aborted if a non-empty intersection of the sets is found in at least one of the runtime instances.
- the rules for how a transaction should be validated may be specific to the application. For example, consider a database of employee records. If one application has changed a phone number of a record, other applications can be considered valid, unless they happen to modify the same phone number. But if the employee name is changed, the identity of any transaction that attempts to modify any part of the record is questionable, and any such transaction should be invalidated. This knowledge, that a phone number is insignificant but a name is significant, may be specific to the application.
- Applicants' system allows the provider to take over the responsibility for transaction validation, by registering itself as capable of doing this, using the standard interface between providers and the runtime. If the provider claims this responsibility, the runtime system asks the provider to validate. The provider fails to validate the runtime it relies on its own, more conservative technique. In a configuration with several providers, while others may do their own, application-specific validation, some may defer the validation to the runtime system. Parallel Validation
- the read and write sets of a distributed transaction are partitioned across multiple instances of the runtime system.
- the transaction commits, its validation is performed in parallel in all of the involved runtime instances.
- the validation can be up to N times faster compared to the time it would take if only one central application server was involved. Given the distributed nature of the ente ⁇ rise wide data access, this case will be increasingly common.
- a long-running optimistic transaction need not wait until the end of its read phase in order to discover that it has been invalidated by another transaction.
- a committing transaction passes the validation phase, it compares its write set against the read sets of transactions that are currently active, and sends invalidation events to all transactions for which the intersection of the sets is not empty.
- the invalidation events are propagated via the distributed event manager that among other features is designed to provide guaranteed and in- order event delivery.
- An application indicates the mode of a transaction when the transaction is started.
- a new transaction can be started in either pessimistic or optimistic mode.
- the mode of a transaction can be different not only on a per-transaction but also on a per- provider basis.
- an application may access two data stores: a private lightweight database used as the local persistent object cache, and a remote departmental database containing shared data.
- Applicants' system allows the application to access the local database in the pessimistic mode, thus avoiding the unnecessary validation overhead.
- the shared database can still be accessed in the non-locking optimistic mode.
- Optimistic concurrency control may provide isolation for transactions accessing such providers when serializability is required. It can also be disabled when it is not necessary.
- Modern database systems provide varying degrees of support for optimistic transaction management. Unlike other transparent data access frameworks that insist on using their own algorithms for managing various phases of an optimistic transaction, Applicants' system is capable of leveraging unique capabilities of different information providers through development of customized wrappers.
- the wrapper API contains basic functions of the optimistic concurrency control that can be re-defined by the wrapper developers. This is not the case with the ODBC, JDBC, and OLE DB APIs used by other systems. Dynamic Transactions
- the state of an object i.e., values of its properties
- the application "Appl” shown in Figure 2 is accessing objects in the cache of the local runtime instance. This is a clear improvement compared to other systems that either leave the object on the server side or in the middle tier.
- a server side object method needs to be invoked the state of the object is on the client and it may be required on the server in order to run the method.
- Applicants' system accounts for this by enabling the transaction manager switch a transaction from an optimistic to the pessimistic mode dynamically while the transaction is running.
- the mode switch is performed transparently for the application at the moment when the application invokes a server side method. Only the provider that is used to run the method is affected. All other providers can continue running in the optimistic mode.
- the mode switch is only necessary if the provider itself does not support a form of optimistic concurrency control. Otherwise, the changes can be saved in the provider as part of the distributed optimistic transaction. For example, the mode of a distributed transaction is never changed when the state of an object is propagated among various instances of the runtime system. This feature is valuable for supporting plug-in service providers, such as the system's own catalog administrator.
- Optimistic transactions are not suitable for applications with high contention on data items accessed by the clients. In such an application, a large number of optimistic transactions would not be able to pass the validation phase causing an unacceptably high rollback rate. While starting all transactions in the pessimistic mode is a straightforward solution to the problem generally used by other systems. It is too limiting in cases when the contention level changes over time. For example, in a real-world situation contention may be high between 8 a.m. and 6 p.m., and low during the rest of the time.
- Applicants' system provides a solution to the problem is facilitated by the neural network agent technology.
- One example of this technology is more fully disclosed in U.S. Patent Application Serial No. 09/084,620, which is inco ⁇ orated herein by reference.
- Transactions are always started without explicit definition of their mode. When the contention is low, they are run in optimistic mode. When the rollback rate grows above a certain limit, the default mode is automatically changed to pessimistic. The rollback rate can be consistently kept within acceptable limits once the Neutral Agent accumulates sufficient knowledge to allow reliable prediction. Session-Wide Event Notification Prior to Commit
- the infrastructure of the Applicants' system extensively uses event notification, usually from providers to consumers. For example, a consumer may be notified that objects held in the client-side cache under optimistic concurrency management have been changed in the database, and hence the current transaction may need to be invalidated. Applications and providers can also send events to one another in a generic way.
- GUI application may consist of multiple windows, some running in the same thread, some running in different threads in the same process, some running in different processes.
- Such different application elements may, for example, be presenting the same data item in different views or different contexts.
- event notification must occur long before the change is committed.
- all the application elements are part of the same process, they will share data through the common session and common cache. This leaves open considerations:
- the object infrastructure is designed to offer significant advantages of reduced development effort, reduced programming errors and improved performance by transferring to the infrastructure many of the responsibilities that would ordinarily rest on the application programmer. This applies also to the work of developing graphical user interfaces (GUIs).
- GUIs graphical user interfaces
- Applicants' system enables a generic user interface to be built based on presenting the state of objects in forms, navigating associations between them, and presenting methods as entries on menus or as buttons.
- the hints of the present invention not only provide direct advantages in improving the workings of the infrastructure or reducing the effort of the developer but also permit the developer to tune the behavior of an application without dropping down to a lower level of abstraction.
- By maintaining the programming conventions at a high level of abstraction most of the advanced functionality of the system remains functional. Examples of such high-level functionality that might be undermined by explicit tuning at a lower level of abstraction include:
- the general object management system of Applicants' system is capable of accommodating different kinds of information and service provides. Its general object model can be adapted to any system that meets the most minimal characteristics of an object system.
- a wrapper an interfacing module for a provider, is written specifically to a provider, and can expose any number of special hints that describe the characteristics of the provider. Applications that are aware of the meaning of these hints can take full advantage of the advanced characteristics of the provider. Applications that do not know anything about the provider operate in the normal way, based on the standard object model. End of Comments.
- Performance Tuning Hints Many providers may specify hints that describe likely optimal ways to process information, given the semantics of the information:
- a projection list a list of the properties that are most likely to be used by the application, and hence recommended to be included in any retrieval;
- GUI Hints A provider can specify hints that suggest how an automatic GUI generator should display the information for example: • Grouping of properties onto tabs of a form;
- Such hints may be provided by either the provider or by the consumer. Without any hints, the system will work in a standard way. Hints from either the provider or the consumer will guide the workings of various system services. If the various hints are in conflict, it is up to the service that uses these hints to decide what to do. Open and Extensible
- Hints are read and inte ⁇ reted directly by the various services of the infrastructure, or by the provider, or by the application itself. Since hints are an official part of the infrastructure's data model, any component can create hints, and any component can use them. Further, since the entire infrastructure is open and extensible, any service may be replaced by another, perhaps one that uses another strategy for inte ⁇ reting the hints. Hints None Cause a Failure
- the object infrastructure defines the semantics of the operations it offers. The hints may give guidance to the infrastructure in how to optimize the operation, but they should not be allowed to be restrictive.
- hints are a form of side-band communication. They are not to be confused with regular object properties. Applicants' system maintains a distinction between hints and regular object properties. Consequently, the definition of new hints, or the deletion of some hints, is not like a change in the schema, and does not require a recompilation of the program.
- any component may define and use them. This means that the various parts of a distributed application can use hints to communicate about how processing is to be done. Using an agreed-upon message convention, a provider can direct a GUI component to bring up related objects and analyze the structure of the relationship.
- the system maintains a cache of all the objects that have been fetched from the database. Any time a change is made to the database, the new values are written into the cache.
- An undo management facility is added to the cache manager. This service records every change in an undo queue. For typical changes to a property value, the undo queue simply records the previous value. For lifetime changes such as creation or destruction of objects, the undo queue records the equivalent operation that would revert that operation: delete for create, create for delete. In practice, the operations that would revert a change may be very complex: for example, if a class is deleted, all instance of that class, all subclasses, all instance of all subclasses, all methods and other facilities of those classes are also deleted.
- the undo manager stores the inverse operations required whenever possible. In some cases an undo operation may not be possible or practical, and in those cases the appropriate notation is stored in the undo queue.
- the undo manager also provides undo and redo functions that the application can directly invoke, as well as support services useful to a GUI, such as listing the sequence of operations in the undo queue in human-readable form.
- a Commit operation consolidates the undo queue, collapsing all the operations in the current transaction into one undo-able operation.
- a specific counter-operation may be known for a specific operation: for a particular method may be specified, in the database schema, the corresponding counter-method.
- the transaction may not be undoable at all.
- the details of how a transaction is handled may be modified in any particular implementation of the system.
- Non-Stack Undo Model The common approach to undo operations is a stack model: actions must be undone in the reverse order they were made, and redone in the order they were made. In principle, however, there is nothing to prevent individual actions to be undone in arbitrary sequence. Random access undo operations are in principle possible, and in some cases quite useful.
- the employees that make up the staff may be in another database, B, under a different schema.
- the application can interrogate the object, find out its location, and adapt itself to the specific schema, for example retrieving the patronymic when one exists.
- Abstract Associations Applicants' system abstracts the concept of relationships among entities as an association. Such an association is defined as part of the schema, and an application program can the services of the invention to navigate the association. Because the definition is abstract, removed from the physical implementation, a provider can use whatever technique it wants for maintaining such relationships, such as foreign keys in a relational database, object references in an object database, methods that execute queries, as long as they are exposed in a manner consistent with the semantics of an association.
- An association is an abstract concept that provides a bi-directional reference between two entities.
- associations can exist between any pair of entities that have a globally unique name, such as e.g. a file with a path, a web page with a URL, an object with a UUID. For example, association from a property of a class can be assigned to a validation method or visualization service for that property.
- An association can also have additional properties of its own, such as the inception date.
- a program such as perhaps a database administration tool used by a human can define types of associations, and create individual associations among the named entities. The program can also navigate using these associations, retrieving either the associated entities or the associations themselves.
- the associated entities are automatically fetched as they are needed: the association is automatically de-referenced as the application navigates over the set of associated entities.
- This automatic de-referencing is made efficient through automatic optimization and self- tuning techniques, for example: • The system does not fetch all of the objects immediately, on the getAssociatedltems statement. A lazy fetch is used, fetching objects from the database as they are needed
- the lazy fetch is not done for each object as it is needed.
- the lazy fetch manager fetches objects in batches.
- the system is self-tuning, adapting the size of the batch to the observed performance of the environment. Rapid turnaround causes batch size to be increased. Slow turnaround causes batch size to be decreased. More complex tuning algorithms can of course be inserted here.
- the performance tuning subsystem also permits the developer to provide hints, guiding the system in its tuning.
- Such a class can be directly used for navigation by programming something like this:
- the last statement tells the system to look for objects of the class Containment, using the property named container to find references to the current object (referenced by cont), and then find all objects referenced by the property contained item.
- the class Containment is not special in any way, it is just a regular class. (This is similar to the way you do joins in SQL, using a regular table without any special characteristics.)
- the present invention makes this concept more general by allowing the Containment class to be registered in the association registry.
- This tells the infrastructure that this class is normally used as an association, but it does not limit the use of the class in any other way.
- Similar registration can be made for other types of associations, including but not limited to: A pair of direct object-to-object references (for a 1-to-l association); Collections of object- to-object references (for 1-to-N and N-to-N associations) and Search methods that retrieve logically associated objects.
- the association registry offers numerous benefits, including for example:
- the Layer 2 generator can create virtual properties based on the registered association types; in the example above, we can register the association through the Containment class under the name contents, and this permits the Layer 2 code generator to create a virtual property contents for the Container class, giving applications an easier way to navigate the associations
- the associations between objects may reference information stored in external providers.
- the boss in the previous example could be stored database A, and the staff in database B.
- the automatic navigation of associations, and the automatic de-referencing of the objects completely hides this distinction from the application.
- the application can navigate between these objects, going from one to the other, without concern for where the objects are located.
- an application may use existing database providers whose schema cannot change.
- information may be stored in the databases of a commercial financial management system, which references people or departments, and it may be desirable to link those references to the corresponding entries in a directory.
- This linking would allow an application to be built that reacts to data in the database and makes decisions based on the organizational data in the directory, perhaps sending email.
- Applicants' system permits the storage of such associations in other databases.
- two databases that don't reference each other, and cannot be made to reference each other, can nonetheless be linked.
- the application navigates the associations in the standard way, the only thing it has to do is specify where the association is stored when it names the association to be used for the navigation. Even this minor inconvenience can be eliminated by registering the association in a registry. This way, the association may be mentioned by name in the standard way, and the system looks it up in the registry, finds where it is actually stored, goes to the external association store to get the link, and then follows the link to the other object.
- This same technique can be used to store associations that reference objects within a single database, in those situations when the schema cannot be changed to accommodate direct storage of the associations.
- API Application Programming Interface
- Every system for accessing information providers or service providers uses a core data model.
- the data model is tables with atomic elements in the cells, extended with stored procedures.
- the data model is interfaces, essentially a specification for a procedure call. The choice of data model is an essential part of every design, because it embodies some tradeoffs:
- the present object model begins with something called an item, then proceeds to define collections of items, introduces the notion of item names, and, finally, named collections and item ownership.
- This data model is called Layer 0.
- This format is built upon to define higher level concepts such as classes and objects, properties and methods (Layer 1), and then on top of that build specific classes such as computers and employees (Layer 2).
- the basic data model (Layer 0) is simple enough that it can accommodate any existing system, without imposing any requirements on an object model.
- Layer 1 the higher level model (Layer 1) is based on the simple Layer 0 model, it can provide a more modern object model and richer semantics for those providers that present such capabilities, without demanding it of simpler providers.
- the implementation of the Layer 1 binding is based on dynamic processing, and is therefore tolerant of inconsistencies and change. If a provider changes its data model, for example if a database schema is modified, the Layer 0 model automatically accommodates the change, and the Layer 1 model does so as well.
- configuration management is a runtime activity: the elements of the system should be to communicate, to negotiate and agree on a common version; each element should be resilient and should be able to continue to operate even when a correspondent is inconsistent.
- a late-bound system such as the IDispatch-based interfaces of COM, is able to adapt to whatever interface an element exposes.
- Applicants' system combines the resilience of late binding and the assurance of early binding.
- Problem: Resilience vs. Convenience Dynamic interfaces allow a consumer to adapt itself the specification of a provider, by interrogating the provider through introspection and reflection services. Such services are commonly provided in component architectures such as COM, and in database access services such as ODBC and embedded SQL. The benefits of these system come at a high price. Programming to these interfaces is quite cumbersome and error-prone. To lessen the burden on application developers, we would prefer an interface that exposes the data model of the business application is preferable, integrating it directly in the programming environment. This is particularly attractive with modern object-oriented languages such as C++, Java and Visual Basic, which directly support relatively rich semantic models.
- the Layer 2 proxy binding exposes objects available in information providers in the form of native classes in a specified programming language.
- a developer defines the schema in the database, and then uses that schema in the application language: the proxy binding is data provider centric. This type of binding provides several advantages over the Layer 1 binding, without sacrificing its core advantages.
- the Layer 2 binding presents the developer with the semantic constructs of the application domain, reducing the development and maintenance effort.
- the Layer 2 binding generates classes in the target programming language or infrastructure, and these classes can be used for compile- time validation.
- a developer can define the initial schema either in the application program or in the database tool.
- a utility migrates the schema definition from one environment to the other. If the original definition was the application program, a database schema is constructed and installed in the database. If the initial definition was the database, source code is generated for use in the application program. The developer can then refine the definition in either location; for example, by adding indexing and clustering definitions, modifying the properties and their types and attributes, adding or modifying server or client side methods.
- the utilities of Applicants' system keep the two environments synchronized, translating the definition from one language to another.
- the code generator used in the proxy model generates code that is compatible with the persistence model preprocessor
- the schema generator and code generator used in the persistence model generate schema and code that are compatible with the proxy system; and • Both code preprocessors and code generators accept and preserve user extensions.
- unified bindings support iterative development. Accordingly, a developer can use the two models iteratively, moving back and forth between the two ways of working.
- unified bindings provide pedagogical unity, limiting an application to a single source code model making the system easier to learn.
Abstract
Description
Claims
Priority Applications (10)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
IL14618000A IL146180A0 (en) | 1999-04-26 | 2000-04-26 | Method and appratus for maintaining data integrity across distributed computer systems |
KR1020017013760A KR20020038575A (en) | 1999-04-26 | 2000-04-26 | Method and apparatus for maintaining data integrity across distributed computer systems |
CN00807915.3A CN1232914C (en) | 2000-04-26 | 2000-04-26 | Method and apparatus for maintaining data integrity across distributed computer systems |
AU45004/00A AU779943B2 (en) | 1999-04-26 | 2000-04-26 | Method and apparatus for maintaining data integrity across distributed computer systems |
EP00926480.5A EP1203296B1 (en) | 1999-04-26 | 2000-04-26 | Method and apparatus for maintaining data integrity across distributed computer systems |
CA002371397A CA2371397A1 (en) | 1999-04-26 | 2000-04-26 | Method and apparatus for maintaining data integrity across distributed computer systems |
BR0010094-3A BR0010094A (en) | 1999-04-26 | 2000-04-26 | Process for maintaining the integrity of data stored across a distributed computer system |
HK02108138.4A HK1052560A1 (en) | 1999-04-26 | 2002-11-08 | Method and apparatus for maintaining data integrity across distributed computer systems |
AU2005200029A AU2005200029A1 (en) | 1999-04-26 | 2005-01-05 | Method and Apparatus for Maintaining Data Integrity Across Distributed Computer Systems |
AU2005200028A AU2005200028A1 (en) | 1999-04-26 | 2005-01-05 | Method and Apparatus for Maintaining Data Integrity Across Distributed Computer Systems |
Applications Claiming Priority (4)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US13101999P | 1999-04-26 | 1999-04-26 | |
US60/131,019 | 1999-04-26 | ||
US09/559,237 | 2000-04-26 | ||
US09/559,237 US7003587B1 (en) | 1996-07-18 | 2000-04-26 | Method and apparatus for maintaining data integrity across distributed computer systems |
Publications (2)
Publication Number | Publication Date |
---|---|
WO2000065458A1 true WO2000065458A1 (en) | 2000-11-02 |
WO2000065458A8 WO2000065458A8 (en) | 2001-03-22 |
Family
ID=26829056
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
PCT/US2000/011554 WO2000065458A1 (en) | 1999-04-26 | 2000-04-26 | Method and apparatus for maintaining data integrity across distributed computer systems |
Country Status (6)
Country | Link |
---|---|
KR (1) | KR20020038575A (en) |
AU (3) | AU779943B2 (en) |
BR (1) | BR0010094A (en) |
CA (1) | CA2371397A1 (en) |
IL (1) | IL146180A0 (en) |
WO (1) | WO2000065458A1 (en) |
Cited By (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
WO2002042851A2 (en) * | 2000-11-24 | 2002-05-30 | Siemens Aktiengesellschaft | Object processing system using an object model |
GB2377345A (en) * | 2001-07-02 | 2003-01-08 | Motorola Inc | Time synchronisation by detecting frequency and phase errors |
EP1469389A1 (en) * | 2003-04-03 | 2004-10-20 | Microsoft Corporation | Playback graph for data synchronization among applications |
US9519528B2 (en) | 2013-04-19 | 2016-12-13 | National Ict Australia Limited | Checking undoability of an API-controlled computing system |
CN113176876A (en) * | 2021-04-23 | 2021-07-27 | 网易(杭州)网络有限公司 | Data reading and writing method and device and electronic equipment |
Families Citing this family (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
KR100738534B1 (en) | 2005-12-12 | 2007-07-11 | 삼성전자주식회사 | Apparatus and method for download of dual module |
KR100956637B1 (en) * | 2007-12-07 | 2010-05-11 | 한국전자통신연구원 | Method for asynchronous data replication in distributed file system and system thereof |
Citations (6)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5867650A (en) * | 1996-07-10 | 1999-02-02 | Microsoft Corporation | Out-of-band data transmission |
US5948060A (en) * | 1997-01-24 | 1999-09-07 | International Business Machines Corporation | Speeding-up communication rates on links transferring data structures by a method of handing scatter/gather of storage blocks in commanded computer systems |
US5987376A (en) * | 1997-07-16 | 1999-11-16 | Microsoft Corporation | System and method for the distribution and synchronization of data and state information between clients in a distributed processing system |
US6029177A (en) * | 1997-11-13 | 2000-02-22 | Electronic Data Systems Corporation | Method and system for maintaining the integrity of a database providing persistent storage for objects |
US6061714A (en) * | 1997-05-07 | 2000-05-09 | International Business Machines Corporation | Persistent cache synchronization and start up system |
US6070184A (en) * | 1997-08-28 | 2000-05-30 | International Business Machines Corporation | Server-side asynchronous form management |
Family Cites Families (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
AU6500596A (en) * | 1995-07-20 | 1997-02-18 | Novell, Inc. | Transaction log management in a disconnectable computer and network |
-
2000
- 2000-04-26 AU AU45004/00A patent/AU779943B2/en not_active Ceased
- 2000-04-26 WO PCT/US2000/011554 patent/WO2000065458A1/en not_active Application Discontinuation
- 2000-04-26 IL IL14618000A patent/IL146180A0/en unknown
- 2000-04-26 KR KR1020017013760A patent/KR20020038575A/en not_active Application Discontinuation
- 2000-04-26 BR BR0010094-3A patent/BR0010094A/en not_active IP Right Cessation
- 2000-04-26 CA CA002371397A patent/CA2371397A1/en not_active Abandoned
-
2005
- 2005-01-05 AU AU2005200029A patent/AU2005200029A1/en not_active Abandoned
- 2005-01-05 AU AU2005200028A patent/AU2005200028A1/en not_active Abandoned
Patent Citations (6)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5867650A (en) * | 1996-07-10 | 1999-02-02 | Microsoft Corporation | Out-of-band data transmission |
US5948060A (en) * | 1997-01-24 | 1999-09-07 | International Business Machines Corporation | Speeding-up communication rates on links transferring data structures by a method of handing scatter/gather of storage blocks in commanded computer systems |
US6061714A (en) * | 1997-05-07 | 2000-05-09 | International Business Machines Corporation | Persistent cache synchronization and start up system |
US5987376A (en) * | 1997-07-16 | 1999-11-16 | Microsoft Corporation | System and method for the distribution and synchronization of data and state information between clients in a distributed processing system |
US6070184A (en) * | 1997-08-28 | 2000-05-30 | International Business Machines Corporation | Server-side asynchronous form management |
US6029177A (en) * | 1997-11-13 | 2000-02-22 | Electronic Data Systems Corporation | Method and system for maintaining the integrity of a database providing persistent storage for objects |
Cited By (10)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
WO2002042851A2 (en) * | 2000-11-24 | 2002-05-30 | Siemens Aktiengesellschaft | Object processing system using an object model |
WO2002042851A3 (en) * | 2000-11-24 | 2004-04-01 | Siemens Ag | Object processing system using an object model |
US8275809B2 (en) | 2000-11-24 | 2012-09-25 | Siemens Aktiengesellschaft | Object processing system using an object model |
GB2377345A (en) * | 2001-07-02 | 2003-01-08 | Motorola Inc | Time synchronisation by detecting frequency and phase errors |
GB2377345B (en) * | 2001-07-02 | 2004-06-16 | Motorola Inc | Time synchronisation system and method |
EP1469389A1 (en) * | 2003-04-03 | 2004-10-20 | Microsoft Corporation | Playback graph for data synchronization among applications |
US7308465B2 (en) | 2003-04-03 | 2007-12-11 | Microsoft Corporation | Playback graph for data synchronization |
US9519528B2 (en) | 2013-04-19 | 2016-12-13 | National Ict Australia Limited | Checking undoability of an API-controlled computing system |
CN113176876A (en) * | 2021-04-23 | 2021-07-27 | 网易(杭州)网络有限公司 | Data reading and writing method and device and electronic equipment |
CN113176876B (en) * | 2021-04-23 | 2023-08-11 | 网易(杭州)网络有限公司 | Data reading and writing method and device and electronic equipment |
Also Published As
Publication number | Publication date |
---|---|
KR20020038575A (en) | 2002-05-23 |
WO2000065458A8 (en) | 2001-03-22 |
AU4500400A (en) | 2000-11-10 |
AU779943B2 (en) | 2005-02-17 |
CA2371397A1 (en) | 2000-11-02 |
BR0010094A (en) | 2002-07-02 |
AU2005200028A1 (en) | 2005-02-17 |
IL146180A0 (en) | 2002-07-25 |
AU2005200029A1 (en) | 2005-02-17 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US7003587B1 (en) | Method and apparatus for maintaining data integrity across distributed computer systems | |
US7680879B2 (en) | Method and apparatus for maintaining data integrity across distributed computer systems | |
US6560609B1 (en) | Delegating instance management functions to underlying resource managers | |
US6594671B1 (en) | Separating privileged functions from non-privileged functions in a server instance | |
US6567818B1 (en) | Employing management policies to manage instances of objects | |
US6502103B1 (en) | Providing composed containers and data objects to support multiple resources | |
US6298478B1 (en) | Technique for managing enterprise JavaBeans (™) which are the target of multiple concurrent and/or nested transactions | |
US6442564B1 (en) | Facilitating workload management by using a location forwarding capability | |
US6457065B1 (en) | Transaction-scoped replication for distributed object systems | |
US9398077B2 (en) | Mobile applications | |
US20060167999A1 (en) | Ensuring a given transactional unit of work arrives at an appropriate server instance | |
US7543000B2 (en) | Method and system combining state replication and operational-replay synchronization | |
US7650432B2 (en) | Occasionally-connected application server | |
US5946685A (en) | Global mount mechanism used in maintaining a global name space utilizing a distributed locking mechanism | |
US6505210B1 (en) | Federation of naming contexts across multiple and/or diverse underlying directory technologies | |
US8156507B2 (en) | User mode file system serialization and reliability | |
US20040123048A1 (en) | Dynamic object-driven database manipulation and mapping system having a simple global interface and an optional multiple user need only caching system with disable and notify features | |
US20040019898A1 (en) | Accessing local objects using local access proxies | |
AU779943B2 (en) | Method and apparatus for maintaining data integrity across distributed computer systems | |
US20040128328A1 (en) | Method and apparatus for relaxed transactional isolation in a client-server caching architecture | |
EP1203296B1 (en) | Method and apparatus for maintaining data integrity across distributed computer systems | |
AU2007202679A1 (en) | Method and apparatus for maintaining data integrity across distributed computer systems | |
AU2007202676A1 (en) | Method and apparatus for maintaining data integrity across distributed computer systems | |
US8433720B2 (en) | Enabling an application to interact with an LDAP directory as though the LDAP directory were a database object | |
Leff et al. | Programming models and synchronization techniques for disconnected business applications |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
WWE | Wipo information: entry into national phase |
Ref document number: 00807915.3 Country of ref document: CN |
|
AK | Designated states |
Kind code of ref document: A1 Designated state(s): AE AL AM AT AU AZ BA BB BG BR BY CA CH CN CR CU CZ DE DK DM EE ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX NO NZ PL PT RO RU SD SE SG SI SK SL TJ TM TR TT TZ UA UG US UZ VN YU ZA ZW |
|
AL | Designated countries for regional patents |
Kind code of ref document: A1 Designated state(s): GH GM KE LS MW SD SL SZ TZ UG ZW AM AZ BY KG KZ MD RU TJ TM AT BE CH CY DE DK ES FI FR GB GR IE IT LU MC NL PT SE BF BJ CF CG CI CM GA GN GW ML MR NE SN TD TG |
|
121 | Ep: the epo has been informed by wipo that ep was designated in this application | ||
AK | Designated states |
Kind code of ref document: C1 Designated state(s): AE AL AM AT AU AZ BA BB BG BR BY CA CH CN CR CU CZ DE DK DM EE ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX NO NZ PL PT RO RU SD SE SG SI SK SL TJ TM TR TT TZ UA UG US UZ VN YU ZA ZW |
|
AL | Designated countries for regional patents |
Kind code of ref document: C1 Designated state(s): GH GM KE LS MW SD SL SZ TZ UG ZW AM AZ BY KG KZ MD RU TJ TM AT BE CH CY DE DK ES FI FR GB GR IE IT LU MC NL PT SE BF BJ CF CG CI CM GA GN GW ML MR NE SN TD TG |
|
CFP | Corrected version of a pamphlet front page | ||
CR1 | Correction of entry in section i |
Free format text: PAT. BUL. 44/2000 UNDER (30) REPLACE "NOT FURNISHED" BY "09/559237" |
|
DFPE | Request for preliminary examination filed prior to expiration of 19th month from priority date (pct application filed before 20040101) | ||
ENP | Entry into the national phase |
Ref document number: 2371397 Country of ref document: CA Ref document number: 2371397 Country of ref document: CA Kind code of ref document: A |
|
ENP | Entry into the national phase |
Ref document number: 2000 614134 Country of ref document: JP Kind code of ref document: A |
|
WWE | Wipo information: entry into national phase |
Ref document number: 1020017013760 Country of ref document: KR Ref document number: 45004/00 Country of ref document: AU |
|
WWE | Wipo information: entry into national phase |
Ref document number: IN/PCT/2001/1151/KOL Country of ref document: IN |
|
WWE | Wipo information: entry into national phase |
Ref document number: 2000926480 Country of ref document: EP |
|
REG | Reference to national code |
Ref country code: DE Ref legal event code: 8642 |
|
WWP | Wipo information: published in national office |
Ref document number: 2000926480 Country of ref document: EP |
|
WWP | Wipo information: published in national office |
Ref document number: 1020017013760 Country of ref document: KR |
|
WWG | Wipo information: grant in national office |
Ref document number: 45004/00 Country of ref document: AU |
|
WWR | Wipo information: refused in national office |
Ref document number: 1020017013760 Country of ref document: KR |