KR19980079611A - Mechanism for locking tool data objects in the framework environment - Google Patents

Abstract

If data such as tool data is generally accessible, concurrent user processes can be duplicated and modified, resulting in incomplete or incomprehensible data. There is a danger of bringing it into a state. The present invention provides a locking mechanism to prevent this. Lock objects are kept in a pool or repository. Two types of locking objects are provided, one is shareable locks that can be shared by multiple user processes and only allows read access to the locked data, and the other one user at a time. Exclusive locks that can be used only by a process and allow the owning process to modify the locked data.

Description

Mechanism for locking tool data objects in the framework environment

TECHNICAL FIELD The present invention relates to the field of data processing, and in particular, to a locking mechanism for common access tool data.

The patent application (IBM Docket No. CA9-97-002) filed by the Applicant in Canada, entitled An Object Oriented Framework Mechanism Providing Common Object Relationship and Context Management for Multiple Tools, relates to a framework mechanism for tool data management. The locking mechanism of the present invention can be used in the environment described in the patent application.

A tool is a unit of software, program, or application module within a program that stores, manages, and retrieves data for a user. All new tools under development include designing, implementing and examining storage mechanisms for tool data. Therefore, the costs associated with the development of new tools (both time and money) are not critical.

Most tools often include their own mechanisms for storing and managing data, which are usually proprietary. Proprietary here means that the details for implementing the mechanism are not shared with other toolmakers or developers. This monopoly causes many problems in customizing and extending existing proven tools to meet the needs of individual users. For example, the interface or view portion of a tool may become entangled with the tool's storage mechanism or model, which may cause difficulties in integrating existing and new views. This phenomenon is called the lack of neutrality of the tool.

In addition, data generated by one tool cannot be used directly or transparently by another tool. Instead, operations are required, such as an export operation that writes data in a different format that matches other tools, and an import operation that reads data in a different format. You must carefully select the operation to export or import

In addition, portions of data imported from other formats may be incompatible with the data storage of the importing tool or may be immediately discarded inconsistent with such data storage. This compromises the round trip integrity of the information, making it difficult or impossible to develop the information repeatedly in one or more tools.

As a result, tool developers must monitor the development or revision of other tools that manage similar data, and add new functionality to export and import the corresponding new data format. In addition to the raw expense of developing and examining new export and import features, there is a delay between when new formats are introduced and when other tools become available to handle the format. do.

Object oriented (OO) programming technology, particularly the OO framework technology, provides a way to solve the cost of continuing to rework existing tools and improves the integrity of the data in using multiple tools. to provide.

[Object Oriented Technoloy Procedural Technoloy]

Although the present invention relates to a particular OO technology (ie, OO framework technology), it should first be understood that OO technology is very different from conventional process-based technology (often referred to as procedural technoloy). Both techniques can be used to solve the same problem, but the ultimate solution is quite different. This difference stems from the fact that the design focus of procedural technology is completely different from the design focus of OO technology. The focus of process-based design is on the overall process of solving problems. In contrast, the OO design focuses on how the solution can be broken down into a set of independent entities that can work together to provide a solution. Independent entities of OO technology are called objects. In other words, in procedural technology, problems are classified into nested hierarchical structures of computer programs or procedures, whereas in OO technology, they are broken down into a set of cooperating objects. Both techniques are very different.

An important feature of OO programming is that objects are reusable software entities that can be combined in different combinations of different uses or with different attributes. An example of this is U.S. Patent No. 5,550,971 entitled Method And System For Generating A User Interface Adaptable To Various Database Management System from West Technologies, Inc., which discloses a variety of information representing a database base scheme. Discusses a dynamic model for creating formal user interfaces. The model can be applied to different database management systems without requiring users to learn different query languages, database systems, and specific database records, fields, and relationships. The model is implemented by a set of concrete classes whose instances represent entities and relationships in various intimacies from the actual database. Objects of these classes are created and interrelated to describe the structure of the database. The model classes provide a standard interface for examining the actual database structure for creating the user interface and for caching database information used by the user interface.

Similarly, US Patent No. 5,428,729 (System And Method For Computer Aided Software Engineering, IBM Corporation) tracks, accesses, and develops the location of data entity documents, such as source code and inspection data. Disclosed are systems designed to refer to translation of data procedures such as compilers, editors, linkers, document formatters, test harnesses within the context of the software project in question. Each new project under development is created from a template by a metaprogrammer and provided through a graphical user interface (GUI). Each user can clone from this master view a user view consisting of a subset of objects from the selected master in accordance with the user's access rights. Through views, a specific flow is described in which a user can access a data entity to edit, define, and dispatch build procedures, and to define and dispatch test cases. Access rights associate users with objects through their classes. The patent describes a method for providing access to files stored in different repositories of appearance and flow of an GUI and arbitrarily, storing rules for translating files from source to target form. A method and method of controlling access through user-specific views of a project. However, since this is not an object-oriented data integration framework, the fundamental difference between this system and the present invention is that a consistent sense of behavior among a number of different unknown tools is provided through the framework of the patented but extensible framework interfaces and protocols. It's not designed to facilitate consistent behavioural feel.

Although terms and phases have been developed that have particular meaning to those skilled in the art of OO design, the word framework is one of the most widely defined words and has different meanings for different people. Therefore, care must be taken when comparing the characteristics of two virtual framework mechanisms to ensure that they are appropriate comparisons.

As will be described more clearly below, in this application the term framework is used to refer to an OO mechanism designed to have core functionality and extensible functionality. Core functionality is part of a framework mechanism that does not require modification by the framework buyer. Extensible functionality, on the other hand, is part of a framework mechanism that is explicitly customized by framework buyers and designed to be extended.

[OO Framework Mechanism]

The OO framework mechanism is typically characterized by an OO solution. Nevertheless, there are fundamental differences between the framework mechanism and the underlying OO solution. Framework mechanisms are designed in a way that allows and facilitates certain aspects of the solution to be customized and extended. In other words, framework mechanisms are more than solutions to problems. The mechanism provides a living solution that can be customized and can be extended to focus on individualized requirements that change over time. As discussed above, customization / extension of the quality of the framework mechanism is very useful to buyers. This is because the cost of customizing or extending the framework is much lower than the cost of replacing or modifying existing non-framework solutions.

So when framework designers embark on solving a specific problem, they must do more than simply design individual objects and how to correlate them. In addition, they are the core functionality of the framework (that is, the portion of the framework mechanism that does not require customization and extensibility by the framework consumer) and the framework's extensible functionality (that is, the framework that requires possible customization and extensibility). Part). Finally, the ultimate value of the framework mechanism is not only about the quality of the object design, but also the design choices regarding aspects of the framework that represent core functionality and aspects that represent extensible functionality.

An example of a framework is U.S. Patent 5,325,533 to Engineering System For Modeling Computer Progams, Taligent, Inc. The framework described in this patent provides increasing interaction and generation and build facilities for the development environment.

The present invention relates to a mechanism for locking data objects for common tool access in an application development environment. The mechanism consists of a repository containing lock objects. Each lock object has a reference counter that indicates when the locking object is completely filled. Lock objects can be referenced by data objects.

1 is a schematic diagram illustrating the class hierarchy for model objects according to the present invention using OMT notation.

2-6 show class diagrams of a framework mechanism in C ++ language, in accordance with a preferred embodiment of the present invention.

7 is a schematic diagram similar to FIG. 1 showing model objects in pairs of classes according to a further preferred embodiment;

8 is a hierarchical category diagram showing a hierarchical category diagram of a framework mechanism constructed in accordance with the present invention using OMT notation.

9 is a state diagram illustrating a locked state of an object.

10 is a schematic illustration of a locking mechanism implemented in a preferred embodiment of the present invention.

11 is a flow diagram showing steps for storing an update of tool data using the core functionality of the present invention.

Fig. 12 is a flow diagram showing the steps for issuing an update notification of tool data using the core function of the present invention.

Preferred embodiments of the invention are implemented in a common data model framework that provides a base for sharing part information between different tools. The framework combines a common repository of information to support partitioning and code generation and model mechanisms to standardize information built by individual tools. An example of a common repository structure as implemented in the above preferred embodiment is disclosed in the applicant's Canadian patent application entitled A Hierachical Metadata Store for Integrated Development Environment (IBM Docket No. CA9-97-003). Reference herein to common reservoirs is included where necessary to fully understand the preferred embodiment of the present invention.

As discussed above, the principle of the framework is that the tool information consists of model objects of various classes and relationships between those objects.

Each model object is characterized by three items: a name, a set of attributes, and a set of relationships including references to other model objects in the framework. The model class hierarchy is shown schematically in FIG. 2 illustrates a C ++ language interface to an object abstract class of a preferred embodiment. 1 and 2, the information associated with the object 1 is defined by a number of individual strings, such as the name of the object 2 and the name of an attribute of the object designed by the object 3. Each attribute (3) contains the value of either the standard string (3a) or blob (3b) (blob is an abbreviation for binary large objects, commonly used in database descriptions, here in bytes. Refers to an amorphous string, which is described in detail below).

4 illustrates a C ++ language interface to a bolb abstract class according to a preferred embodiment. Values that are too complex or highly structured and cannot be represented in string form can be implemented as a kind of blob. Every bolb must provide an action to set and inspect the segment of data entered by the string, with the interpretation of the string entirely dependent on the blob.

Another feature of the preferred framework mechanism is that the relationship (4) of the model objects shown in Figs. 1 and 2 is defined as a separate class and has a mutually exclusive name. Figure 3 illustrates the C ++ language interface to the relation abstract class of the preferred embodiment which defines a portion of the attribute set below.

Referring again to Figure 1, all relationships (4) of the model object are characterized by the name (5), which is a string. Each relationship 4 also includes a set (0 or more) of references (6) to other model objects. Relationship (4) provides an operation for checking the name of the relationship and adding, checking and removing any references to that relationship.

The function of reference (6) is to load model objects from disk into memory if they are not already in memory. References must be bidirectional. If one object refers to the second object, the second object includes, in one of its relationships, a reference reply to the first object. References are also either strong references or weak references. When a model object 1 is deleted, all model objects strongly referenced by the model object 1 are also deleted. On the other hand, if an object that weakly references another object is deleted, only the bidirectional reference to the deleted object in that other object is deleted. Two different mechanisms illustrated in FIG. 1 should also be defined. There is a search context (7) and a lock context, which has three features: deletion lock (8), rename (9), and change lock (10).

Model objects that may appear in different contexts depend on the path through the model to the object. 5 illustrates a C ++ language interface to a search context abstract class according to a preferred embodiment. The search context (7) represents a path along a subset of objects in the model. The search context provides the behavior for finding and inspecting attributes, and when requested to find an attribute, the model's context is reached until it encounters an object with the requested attribute or reaches the end of the list. Navigate along the list ((10) in FIG. 5). If an object with the requested attribute is found, the value of that attribute is returned ((11) in FIG. 5). Thus, different search contexts indicate that a single object in the model has different attributes.

Relevant model objects must be locked by the tool before they can be changed by the tool. Locking will be discussed in more detail below in connection with a preferred embodiment of the framework hierarchy. To change the properties of a model object, only the object itself needs to be locked. In order to rename a model object, the object itself needs to be locked with all relationships that refer to the object by name. In order to delete a model object, the object itself and any objects that are strongly referenced by the object directly or indirectly, as well as any relationships that reference these objects, must be locked. Each object in each relationship can be locked independently, and this basic behavior is enough to make it as simple as changing the object's properties. The model framework includes lock context objects for handling more complex rename and deletion scenarios. 6 illustrates the C ++ language interface for the abstract class of the delete lock context 8 and the rename lock context 9.

The rename lock context can be constructed from the model object before renaming the object. Since some relationships can be a key to the name of an object, the rename lock context locks the model object within any relationship that contains a reference to the object. The delete lock context can be constructed from the model before deleting the object. The delete lock context locks any model object that can be reached by the model object and the strong reference chain (since under the framework, these model objects are also deleted), and contains any references to all of those objects. Will lock the relationship. These references should be removed from the relationship to prevent dangling references.

In a further preferred implementation, the object classes are actually a pair of classes consisting of an abstraction class and an implementation class. This is illustrated in FIG. 7. Every model object includes an abstraction object 11 that includes a reference 13 to the corresponding implementation object 14.

The complete interface to the object and its behavior is provided through its abstraction. But only the name (12) of the object is actually stored in that abstraction. The attributes 15 and relationships 16 of the object are concealed within the implementation part. The request for any information about an object that exceeds its name is secretly satisfied by the implementation part and possibly some of the relationships contained within that implementation part.

Since the abstraction, implementation and relationship objects persist independently, the need for the name of the object will result in the cost of loading the abstraction part from disk 17 without any implementation part or relationship. This technique minimizes the amount of data transferred from disk to satisfy the inquiries and improve the overall performance of the tools in the framework.

Using the above definitions, the framework of the preferred embodiment provides an environment and support mechanism for implementing a flexible inclusion hierarchy of development parts. Base classes define the standard behavior for partial locking references (called containment support) between objects, property / property access, identification of runtime formats, and persistence. All the tools derive specific implementation from the base class. 9 illustrates an abstract foundation hierarchy according to a preferred embodiment of the present invention. The core functions of this hierarchy are Persistence 20, Notification 21, and Locking 22, identified as base classes in the hierarchy above the dotted line. This does not mean that all of these classes cannot be overwritten as can be done in the C ++ language programming language, but some form of persistence, notification, locking is the core functionality required for the framework of the present invention to operate. Classes below the dashed lines beginning with IDE element 24 illustrate some of the data model formats that may be included in the framework hierarchy. These additional classes are defined in the appended appendix, and many additional classes are described in the detailed description of the patent application (IBM Docket No. CA9-97-003) filed concurrently with this application.

Inheritance in the framework hierarchy of the present invention operates to provide the following form. Persistence services maintain state within the file system of the host computer and share this data among various executable programs. Model objects derived from the framework hierarchy are grouped into files in the file system. Objects in the file system are referred to as committed models. When you run a program that uses the framework model, you see only the data in the commit model. All changes to the model are performed on internal memory copies of model objects in the private address space of a single executable program.

The locking service performs mutual exclusion from modifications to the model. Because each executable program creates changes to a dedicated internal memory copy of the model object, two programs cannot update or delete the same object at the same time. The locking service provides a mandatory locking method that prohibits concurrent access. This is explained in detail below.

With reference to FIG. 9, the inheritance from the persistence base class 20 provided by the model object is constructed from the default local heap of each program and shared by persistence through the file system of the host computer. In many C ++ language implementations, dynamic or runtime binding is typically implemented as a pointer within each object to a class-specific table of constant method pointers. Manner table pointers are typically stored in a dynamic link library or executable program, but are not accessible because all executable images are different from each other and the locations of the tables are different. Thus, in a common implementation method, it is not possible to store C ++ language objects in shared memory, nor is it possible to access the data of those objects from different executable images.

The persistence service of the present invention avoids this problem through default local heap construction.

In addition, persistence class 20 provides a mechanism for all classes in the framework for writing to and reading from disk. Every derived class in the model that extends the underlying object state must provide its own way of reading and writing, but persistence classes also support the streaming operators that classes use to convert between the disk and internal memory types of an object. Define a mechanism for streaming the object to ignore. Streaming operators execute their own read and write methods for each object to perform the actual processing. The following implementation conventions are used for all classes in defining read and write schemes for the derived classes of the preferred embodiment.

In a preferred embodiment, the framework provides a standard interface for implementing forced mutual exclusion for C ++ language objects. Classes using this implementation are derived from locking class 22. Locking 22 is itself a subclass of persistence 20 because mutual exclusion is only required for objects shared between executable programs.

The locking method provided by the locking 22 is described below. However, there are two cases where this mechanism is inappropriate: first, in the case of a global parts list, which is a data structure that is guaranteed to contain all objects of a particular type; Second, in the case of a dirty pool, which is a mechanism for updated meta information that is stored with a model object but is not part of that model object.

Locking class 22 is a model abstraction for persistent objects that can be locked. Locking class 22 provides the locking primitives used in the model. In general, these primitives are not used directly, but are called as part of a composite object lock. The object lock consists of two stages;

1. A lock identifier is obtained for the planned type of operation. In a preferred embodiment, the lock pool is a singleton located within a scalable shared memory pool that manipulates fixed size named shared memory segments as described below. C ++ language class. Because of this, the lock identifier is the actual array index into the pool.

2. The shared lock or exclusive lock is configured by instantiating the lock object type using the obtained lock identifier. In a preferred embodiment, the lock is obtained by way of a C ++ language constructor, which is usually used as a local instance so that the destructor is automatically executed even if the code block exits. Lock acquisition failures are propagated through exceptions. Destructors free up locks in most cases, with one exception being the update lock context.

A single class refers to the C ++ language programming conventions, which can be the only one live class instance per process.

The use of a scalable shared memory pool as a repository for lock objects apart from the tool data model objects themselves is known as the Locking Tool Data Object in Framework Environment filed with IBM Docket No. It is disclosed in CA9-97-010.

Scalable shared memory pools are a peer to peer pooling mechanism that involves allocating fixed size segments from a system's named shared memory pool. The name of the segment is generated by taking a predefined character sequence and assigning a segment number (starting at zero). Each process has a single pool that manipulates the pool segments for that process. If a new segment is required, the name is calculated and an attempt is made to find the segment in current memory. If a segment in the current memory is not found, the segment is allocated. This process requires that the first process requesting the memory segment allocates the segment and all subsequent processes are synchronized to access the segment again (peer-to-peer approach as opposed to client / server). . Each single pool class in a process maintains an array of all segments it knows about. This is a quick indirection into the array that allows access to any segment in the process. In addition to the arrangement of segments, a specific named area is allocated which contains the full information about the pool. The name of this area is fixed and assigned by the first process to start its own pool. Access to the entire information in the pool is synchronized to avoid race conditions between two or more processes.

Each segment is treated as an array of objects of fixed size and divided into n pieces of size x (where x is the size of the object in the pool). If each process needs a piece of storage, it needs to get a pool id. The pool uses the entire segment of information to find the highest index currently allocated. If the next high index value still exists in the segment (ie not a multiple of n), it simply returns. Otherwise, a check is made on all objects currently in the pool to find unused objects. In order for a single class to perform these checks, each of the n pieces of storage in the full segment must have an indicator to indicate whether it is used. If an unused object is found, its index is passed back and the storage is marked as used, otherwise a new segment is allocated.

Once an index is distributed, that index can be used to access shared memory storage through a particular pull method. The pull method simply takes an index and calculates the segment number and index in the segment. Then access the array of segment addresses and compute the address of the object in the segment. In this way the same id can be used by multiple processes even if shared memory can be allocated to different virtual addresses, which is the case for legacy platforms such as Windows ^TM NT. The formula is as follows:

Segment number = fullId / n

Segment index = poolId coefficient n

The pool is scalable because it allocates segments when needed. This pool is peer-to-peer, so it doesn't matter how many processes are included or in what order these processes are started (no server is needed). The mechanism only needs two indirections to access any item by its id.

In a preferred embodiment of the present invention, the lock object format is as follows.

1. Shared lock: shared read-only access

2. Exclusive lock: Restrict read / write access to one process.

As shown in the state diagram of FIG. 9, configuring a lock object locks access to the basic lockable model object. In most cases, destruction of the lock object is necessary to unlock the access. Thus, shared restriction read / write access to the underlying model object is restored by realizing the erase lock format to eliminate the instantiation of the shared lock format. This ensures that the object is not deleted and allows others to read or update the object (ie, obtain a shared or exclusive update lock). The exception is when a locked base object is updated. The lock can be destroyed if the update is saved.

Forced locking for configuration and destruction is enforced by rules. Constructors and destructors of framework classes are protected. This prevents the program from creating or deleting objects directly. Instead, methods for creating and destroying class data are provided for all framework classes. The creation method obtains the lock needed to create the object and insert it into the existing model before constructing the object. The destruction method obtains all locks needed to remove all references to the object from the model before deleting the object. The canceled update operation is aborted as a result of the lock acquisition failure, the model state is unchanged, and the exception is discarded.

The lifetime of a lock depends on both the persistence subsystem and the existence of the lock object referencing the lock in memory. This is shown in FIG. The lock object class 100 has a shared lock 102 and an exclusive lock 104 as derivatives thereof. The difference between them is that shared locks can have multiple processes, while exclusive locks are exclusive only possible for one process at a time. A single process resource can have one exclusive lock or one or more shared locks for that process.

When the lock object 100 is realized by the lockable object 106, the lock is positioned by referencing the lock pool 108 via the lock ID assigned when the lockable object is configured. Lock 112 in lock pool contains the process ID of lock owner 116. Attempts to reacquire locks already owned by the lock owner are also allowed.

In the case of a shared lock, the process ID is always a dummy or reserved identifier. The same fake identifier is used by all attempts to obtain a shared lock. Thus, if a shared lock is already held by any process, the process ID matches and is granted a lock. In order to track the number of shared lock owners, a reference counter is used. The reference counter is incremented each time a lock is acquired and decremented every time the lock is released. When the counter reaches zero, the lock is no longer owned by any process and can be used as either a shared or exclusive lock.

In the case of exclusive locks, the actual process ID is used to prevent sharing. Exclusive locks of a particular type are modify locks that track the update status of a locked object. If the object is not updated, the lock is freed immediately when its destroyer is executed. When a locked object is updated, the update lock is not released by the update lock destroyer until all changes to the locked object are delegated by storage or all changes are canceled. If the update lock is not destroyed (although the save is performed), the object remains locked. The program can depend on this behavior to maintain the locked object through storage.

Two exceptions have been described above for the use of the locking mechanism, the full list of parts and the dirty pool.

The full list of parts contains the specified set of unique objects. In the framework of the preferred embodiment, this is contained within a single object that is a single class. When a shared memory list is implemented that contains a data structure that detects name clashes, one part is added to the entire list in one program and the name of that part is a list of delegated parts. And uniqueness is checked both in the shared list of names of non-delegated parts. If the name is not unique, the add operation fails and the exception is discarded. Otherwise, the insert operation is complete and the name is added to the shared heap to prevent other programs from using that name. Each executable program maintains a list of inserted objects. While the save operation is in progress, the program removes all these objects. By storing only names, scalability is provided in which the amount of shared memory used to avoid name collisions within the entire group of parts is minimized.

The second exception is a dirty pool. It refers to an index pool that tracks whether an object has been updated without an update corresponding to the source code file. If the object's dependencies change, the object must be replayed. Not updating the real object not only improves performance but also reduces lock contention between processes. If there is a lack of concurrence of the object and its source file, the object is referenced by the name of the index pool, such as polluted or dirty. Dirty pools use a scalable shared memory pool mechanism to support remote data for shared objects. Remote data is an encapsulated object state that does not depend on the object. This data can be updated without locking the object, updating the object, or storing the object order, thereby reducing the need for lock contention between processes. The pool uses the lock pool indexing method, and one object is assigned one identifier, which is a bit segment in the dirty pool index whose lifetime of the model object is permanent. Each dirty pool segment is split in half. The first half has the internal-use bit and the second half has the dirty status bit. The pool is durable in the preferred embodiment. The dirty pool streams itself in both directions with the disk. In this way, information as to whether or not the source for the object needs to be played can be queried in subsequent sessions.

When implementing changes to the model, there are three requirements for persistence services.

A program cannot read a new version of an old object while running from an executed model.

2. Failure to complete a change record for a file cannot corrupt the executed model.

3. Changes made within one program cannot overwrite changes made by another program.

The storage is implemented as a two step execution into a file system that is synchronized by an internally processed communication protocol. This process is shown in the flowchart of FIG. The internal process communication protocol uses two events, save pending and save complete. These events are implemented as a shared memory flag, a shared memory counter, and two host system semaphores called notify and acknowledge.

If the storage program sends a save pending event (block 40), the storage begins. Sending an event may include setting the event shared memory flag to true, initializing a model shared memory count for a large number of programs connected to the model, and resetting the acknowledgment semaphores. And post a notify.

If the flag file indicates that phase 1 of storage has begun, the storage program records all files that have been updated to temporary files (block 44). If temporary files are still using the model, storing them in a temporary file prevents other programs from accessing the temporary file. This satisfies half of the first part of the secure storage target so that no other program can mix objects from the executed model with objects in the temporary file.

Once the storage program has finished writing all changed files to the temporary file (block 46), the storage program waits for the save pending event to complete (block 48). This is acknowledged for the transfer program when an acknowledgment semaphore is posted.

Save pednding events are processed by worker threads found within each program attached to the framework model. When an event is received, the worker thread wakes up. The thread determines whether a program is attached to the model being stored by comparing all models opened in the program with a model with a set of storage flags. If the program is glued to the storage model, the cross thread package is used to post a notification to the program main thread. This notification is received asynchronously (block 58) after the main thread has completed processing of all GUI events and notifications received prior to a saved pending notification.

If the program main thread receives the same wait notification, it stops demand-loading and changing in the model (block 60). This completes requirement 1 above, and the program cannot mix existing and new objects.

If other programs receive the storage wait event, the shared memory counter is decremented to acknowledge receipt of the event (block 62). If the decrement counter is 1, all programs have processed a notification and acknowledge semaphore events are posted to indicate that these events have completed (block 64) to wake up the transmitting program ( Block 48).

When the save pending event is complete, the storage program flags the first phase of the storage completion via the disk flag files (block 46). Before this point, interruptions, such as system crashes, lose all changes but leave the database in a consistent state.

If no error occurs, all the data needed to access the modified version of the model is written to disk and it is impossible for a system or program crash to leave the on-disk model in an inconsistent state. Do. The storage program then renames all temporary files to their proper names and removes all empty data files from the executed model (block 50). This means that all changed files have replaced their contents with versions in the temporary file, which satisfies the second requirement of safe storage.

The store program sends a save complete event to the standby worker thread and the program main thread to indicate that the on-disk model is in a consistent state for all other programs (block 52), and the clean up phase (block Wait for the event to complete before performing 56) (block 54).

Another core function found in the notification base class 21 of FIG. 8 provides a mechanism for communicating to other users changes to the tool data in the framework. This is also shown in FIG.

If all programs connected to the model receive a save complete event (block 64), they wake up. These programs then invoke a framework replay method that visits each file program that opens and loads the latest revision of each changed object (block 66). Once this process is complete, every program contains a private internal memory version of the model that matches the most recently saved changes. If the program contains any objects that have been deleted and changed by the stored program, the program receiving the save complete event also sends a model / view / controller notification sent to all observers of the affected objects. (Block 68). Observing these notifications is a hook that the program uses to create an internal state that matches the changes made to the model. After performing playback, each program recognizes receipt of a store complete event (block 70).

When the save complete event completes, the save program and all worker threads are woken up. The storage program completes the remaining housekeeping tasks and returns from storage. The worker thread returns to a wait state on a save pending interprocess event.

In a further embodiment of the present invention, the persistence service returns to a known good state in the failure event because it is not always impossible to predetermine whether the operation of changing many model objects will complete successfully. Provide the ability for This process is shown in FIG.

The checkpoint mechanism restores the program's dedicated internal memory state. The state to be saved includes the deletion, creation, and updating of all objects that have occurred since the program saved the startup or model, as well as the persistence service data structures used to manage the objects and data files. While the checkpoint mechanism is in operation, this data is kept in a temporary file.

The program invokes a checkpointing mechanism that marks the beginning of an update that may require a restore of the previous state (block 76). The persistence subsystem then visits each persistence file opened by each program on the model. The persistence subsystem identifies objects that are different from the state in which the internal memory state is executed (block 78). In memory, the updated object is flagged by being stored as a temporary file (blocks 80 and 82).

If the attempted update is not successful, the roll back method is invoked because the exception is usually discarded and caught (block 88). The rollback method regenerates objects deleted after the checkpoint, removes objects created after the checkpoint, and states the state of the persistence service data structure for the state of all updated objects and the state of those objects when the checkpoint is called. Resave (block 90).

If the process determines that the algorithm has completed successfully (blocks 84 and 86), it releases the resources used by the checkpoint mechanism and invokes a commit to flag the internal model state as consistent.

Modifications to the above preferred embodiment of the present invention which are apparent to those skilled in the art are included in the appended claims.

If data, such as tool data, is generally accessible, there is a risk that concurrent user processes create overlapping modifications and leave data in an incomplete or incomprehensible state. The present invention provides a locking mechanism to prevent this.

Claims (7)

In the data object locking mechanism for common tool access in the application development environment, a) a repository containing lock objects having indicators for indicating whether the state of the own process is occupied or free state; and b) a data object locking mechanism comprising means for referencing a lock object from the data object. The method of claim 1 wherein the lock object a) shareable locks adapted for use by multiple self processes and b) A data object locking mechanism that includes exclusive locks that are made suitable for use by one own process at the same time. 3. The data object locking mechanism of claim 2, wherein the indicator to indicate that a sharable lock has been used comprises a reserved process identifier adapted to be copied onto the sharable lock by one or more of its processes. . 3. The data object locking mechanism of claim 2, wherein an indicator to indicate that an exclusive lock has been used includes the process identifier of its own process. 3. The method of claim 2, in the case of exclusive locks. a) means for determining whether the referenced data object from the exclusive lock has been updated and b) means for destroying the lock object further comprising means for delaying lock destruction until any update to the data object is stored. 3. The data object locking mechanism of claim 2, wherein the exclusive locks are adapted to persistence through save if not explicitly destroyed. 3. The data object locking mechanism of claim 2, wherein a lock object in a free state can be used by its own process as either a sharable lock or an exclusive lock.