WO1995030955A1 - Datenverwaltungssystem eines realzeitsystems - Google Patents

Datenverwaltungssystem eines realzeitsystems

Info

Publication number
WO1995030955A1
WO1995030955A1 PCT/DE1995/000583 DE9500583W WO9530955A1 WO 1995030955 A1 WO1995030955 A1 WO 1995030955A1 DE 9500583 W DE9500583 W DE 9500583W WO 9530955 A1 WO9530955 A1 WO 9530955A1
Authority
WO
WIPO (PCT)
Prior art keywords
data
transaction
management system
access
generation
Prior art date
Application number
PCT/DE1995/000583
Other languages
English (en)
French (fr)
Inventor
Stefan Krusche
Dirk Lukas
Stefan Lang
Jürgen LANTERMANN
Original Assignee
Siemens Aktiengesellschaft
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Siemens Aktiengesellschaft filed Critical Siemens Aktiengesellschaft
Priority to EP95916579A priority Critical patent/EP0760130B1/de
Priority to JP7528595A priority patent/JPH09505681A/ja
Priority to DE59501924T priority patent/DE59501924D1/de
Priority to US08/737,044 priority patent/US6662202B1/en
Publication of WO1995030955A1 publication Critical patent/WO1995030955A1/de

Links

Classifications

    • 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/466—Transaction processing
    • Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y10—TECHNICAL SUBJECTS COVERED BY FORMER USPC
    • Y10S—TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y10S707/00—Data processing: database and file management or data structures
    • Y10S707/99951—File or database maintenance
    • Y10S707/99952—Coherency, e.g. same view to multiple users
    • Y10S707/99953—Recoverability
    • Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y10—TECHNICAL SUBJECTS COVERED BY FORMER USPC
    • Y10S—TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y10S707/00—Data processing: database and file management or data structures
    • Y10S707/99951—File or database maintenance
    • Y10S707/99952—Coherency, e.g. same view to multiple users
    • Y10S707/99954—Version management

Definitions

  • Data management systems of real-time systems should offer their user systems fast and secure (consistent) online management of different data generations.
  • the invention has for its object to provide a data management system that meets the above requirements.
  • the management of different data generations is based on the same data objects as are also used by the transaction management system , carried out. This enables fast and secure online administration.
  • an embodiment of the invention is indicated by claim 2.
  • the new data objects generated in the context of a transaction are combined to form a data generation and can thus be identified unambiguously by their GEN_ID according to their order of origin. This makes it possible for the generation management system, for example, to jointly share a data generation that is no longer required, i.e. with a single delete request.
  • Another embodiment of the invention is specified by claim 3. This embodiment enables reading sequences parallel to a transaction to be carried out.
  • An embodiment of the invention is indicated by claim 4. This embodiment prevents the access of transactions parallel to a transaction to the same data object.
  • the dynamic assignment enables the treatment of data objects of different granularity. This means that a TGSE can be assigned both to a data object of the smallest granularity (data element) and to a data object of greater granularity (data group).
  • the aforementioned dynamic assignability is achieved in that the TGSE are either generated dynamically when required or are taken from a common pool.
  • the TGSE can be linked by the transaction management system according to their order of origin to form a generation tree, which is then managed by the generation management system.
  • This embodiment requires the dynamic allocation of the TGSE.
  • the arrows between the system blocks represent a functional relationship (e.g. a procedure call, the head of an arrow pointing to the called procedure).
  • the data management system consists of two layers, namely an application-specific system layer, which is referred to below as the application-specific database ADB, and an application-independent system layer, which is referred to below as the generic database GDB.
  • the generic database GDB comprises central and local functions, the central functions being implemented in a central control system CU and the local functions being implemented in generic modules GM.
  • the central control system CU contains a central access control system CTCC, which controls access (individual accesses or access sequences) centrally, general access algorithms ALG, a security system VSI, which realizes the interface to a background memory for securing the user data, a data pool VLP for managing data of variable length and a central distribution system DDFC, which is used to distribute updated user data to the various processors of the real-time system.
  • CTCC central access control system
  • ALG access algorithms
  • VSI security system
  • VLP data pool
  • DDFC central distribution system
  • a generic module GM represents a definition module for describing a data container, which contains data structures for storing the user data and the access structures required for this, ie addressing methods and elementary access procedures.
  • the generic modules contain additional structures for supporting the central functional system, ie structures for supporting coordination and ensuring consistency (local access control system CTCL), as well as structures for supporting the distribution of user data on different platforms (local data distribution system DDFL ).
  • the structures in the generic module are described in a manner that is independent of the user, ie in a manner that is independent of the data layout of the data structures.
  • Different types of generic modules are generated by combining modules (for example local access control system CTCL, local distribution system DDFL as well as additional data definitions necessary for this, various addressing methods). The variants are determined by the requirements which result from the data modeling of the corresponding application.
  • Each generic module contains a set of elementary access procedures which relate to the control of an individual access. This set includes a procedure GET for reading user data, a procedure SET for modifying user data, and procedures CREATE and DELETE for creating or deleting data elements of the user. Access to the data of a user is only possible via these special access procedures (data encapsulation). Data with the corresponding persistence requirement is saved in a core image format on a background memory. This ensures that the current data is available as quickly as possible after restarting the exchange computer with the associated loading process.
  • the application-specific database ADB comprises views and module instances, the module instances being generated from the generic modules by instantiation.
  • the data containers (generic modules) are initialized with certain data declarations, as a result of which the data structures and the access algorithms for these data structures are related to one another.
  • the views form the interface to the current application APPL. They represent the logical picture of the conceptual data model of this application.
  • the access control system controls the access of users to the data management system EDB and thereby ensures that an update process the data in the data management system.
  • Management system transferred from a consistent initial state to a consistent final state.
  • the access control system treats access sequences (transactions or read sequences) in a holistic (atomic) manner, ie a transaction is either carried out holistically or rejected holistically.
  • the access control system coordinates the simultaneous access of mutually parallel access sequences.
  • the access control system comprises the CTCC, which carries out control tasks (e.g. START_TA, DO_TA, ABORT_TA) for the user that relate to the control of an access sequence in its entirety.
  • control tasks e.g. START_TA, DO_TA, ABORT_TA
  • the central data pool VLP manages semi-permanent and transient data of variable length. It contains both the data and a set of primitives in order to store and manipulate the data it contains.
  • All data managed by the central data pool is encapsulated by the data pool. All access to this data can therefore only take place via the primitives mentioned.
  • the module instances mentioned can have the data pool reserve a block of any length, each reserved data block being identified by a logical key assigned when it was reserved.
  • the generic access algorithms ALG include functions that are common to all generic modules, namely for an algorithm for the logical organization of data storage (for example linked list, binary tree), and for other mechanisms for the physical storage of the data, that is to say data structure-independent paths through internal data bases Administrative or handle structures.
  • the generic access algorithms are only called by the generic modules.
  • the DDFC controls the transfer of user data from one platform (processor) to other platforms (processors) and thereby ensures data consistency between different platforms (processors).
  • the DDFC is called dynamically by a DDFL of a user module.
  • a generic module serves as a data container which describes data structures and access algorithms specific to these data structures in an application-independent manner, i.e. in a manner that is independent of the data layout.
  • a generic module comprises a set of access procedures to the data management system which it makes available to the respective application in order to thereby have read or write access to the data contained in the generic database GDB.
  • the generic modules form a library (Library), classes of the application-specific p ⁇ ⁇ can be generated by instantiating ,, ie by replacing general data layout information (Placeholders, in CHILL eg ANY_ASSIGN) by specific
  • An application procedure is used to access one or more user modules, with one user module each managing an object class.
  • An application procedure contains the desired attributes of the respective data object as parameters, these parameters being return parameters which are returned to the application after the user procedure has been carried out.
  • the application procedure thus provides the application with its own view of the stored application data. Changes in the logical data structures therefore have no effects on the applications.
  • An application or a user only uses the VIEW application procedures to manage his user data.
  • a corresponding sequence of user procedure calls is identified as a transaction by commands to the central access control system.
  • the execution of the transaction as well as the backup of the data in the background memory and the distribution of the data is carried out independently by the data management system and is therefore completely invisible to the user.
  • 3 shows the preparation phase and the activation phase of a transaction.
  • the transaction is built up step by step by the user the access procedures (SET, GET, etc.) for individual accesses are called up one after the other.
  • the access procedures SET, GET, etc.
  • any number of individual accesses can be initiated within a transaction by calling the corresponding access procedures.
  • the preparation phase is started by the START_TA procedure and ended by the DO_TA procedure.
  • the START_TA procedure assigns a transaction identifier TA_ID to the transaction and transfers it to the user. The user then uses this TA_ID as an input parameter when calling up the access procedures for individual access.
  • the preparation phase the calls to the access procedures are recorded and any changes to the data affected by the access are prepared.
  • the user has the option of rejecting the transaction by calling the ABORT_TA procedure.
  • the activation phase is started at the same time, which is controlled exclusively by the central access control system and therefore runs independently of user calls. No further calls for individual accesses can thus be taken into account in the activation phase.
  • the coordination of a transaction is carried out in the preparation phase, ie all collision cases with other parallel transactions are identified and coordinated.
  • the coordination takes place in such a way that such transactions which were started earlier can be continued, whereas other parallel transactions are rejected by returning a corresponding negative feedback to the user. Since all collision cases are resolved in the preparation phase, transactions in the activation phase can be carried out independently of one another.
  • 4 shows the structure of the central access control system CTCC.
  • the central access control system CTCC comprises a transaction management system TMS, a generation management system GMS, a resource management system RMS and a collision management system CMS.
  • the transaction management system TMS controls the transaction-oriented access to the data objects OCI of the data management system.
  • the generation management system GMS manages the data generations generated in the context of transactions on the basis of a generation identifier GEN_ID assigned by the transaction management system during the activation phase of a transaction. This management involves updating a newly generated data generation, i.e. the transfer of the new data generation to its final storage locations in the working memory and / or on the disk.
  • the management mentioned includes the control of reading sequences (sequences of logically related read accesses to the data objects of the data management system).
  • This type of administration enables a group of data objects of one and the same generation to be read in the context of a read sequence while a transaction is taking place in parallel.
  • the resource management system RMS manages the access data structures that are used when the transaction management system and / or the generation management system is accessed.
  • the collision management system CMS coordinates write accesses to one and the same data object, which are triggered by parallel transactions and prevents the oldest data generation from being deleted while at the same time a read sequence wants to perform read access to data objects of this data generation.
  • the RMS comprises a switch pool TGS_POOL, which is used both by the transaction management system TMS and by the generation management system.
  • the switch pool is used to maintain (temporarily store) new data (transaction-oriented entries) received by the transaction management system TMS as part of a transaction until they are stored in their final storage locations in the memory and on the disk by the generation management System have been filed.
  • the RMS also includes a logbook TG_LOG, which enables a suitable administration of the transactions, an area table SCOPE_TAB, which is used to manage the different data generations, and, as the smallest administrable data structure, the switch structure TGSE already mentioned.
  • a logbook TG_LOG which enables a suitable administration of the transactions
  • an area table SCOPE_TAB which is used to manage the different data generations, and, as the smallest administrable data structure, the switch structure TGSE already mentioned.
  • FIG 5 shows the architecture of the switch pool TGS_POOL.
  • the architecture of the switch pool comprises 10 transaction sheets TL with corresponding headers 0 to 10. This means that the transaction management system supports 10 transactions in parallel, since each transaction sheet TL is reserved exclusively for a specific transaction by assigning one Transaction ID TA_ID is entered in the corresponding data field of the associated header. An additional eleventh transaction sheet is provided in order to enable an active transaction to continue executing even if its associated transaction sheet runs short due to a lack of sufficient available memory (indicated by a FREE_MEMORY data field within the header).
  • a data field TA_ID of the header must not have an entry.
  • a data field STATE of the header which indicates the status of a transaction must indicate the status "free”.
  • the data content of the STATE data field is a transient parameter within the semi-permanent transaction sheet, which is necessary in order to continue to reserve a transaction sheet during an update phase, although the semi-permanent parameters FREE_MEMORY and TA_ID already make the transaction sheet reusable for other transactions. display.
  • FIG. 6 shows the architecture of a transaction sheet, in particular the data fields contained in the header of the transaction sheet TGL.
  • a data field BEGIN_USED_AREA indicates the beginning of the memory area which is used by the transaction sheet TGL to store the input data of a transaction.
  • a data field END_USED_AREA indicates the end of the memory area mentioned.
  • the data field END_USED_AREA also shows the beginning of the memory area, which can be used by another TGL.
  • a data field LENGTH_USED_AREA contains a redundant parameter for monitoring purposes, which indicates the difference in the memory between the content of the data field BEGIN_USED_AREA and the data field END_USED_AREA.
  • a data field END_UPDATED_AREA indicates the current end of the memory area already transferred from the transaction to the disk.
  • 7 shows the structure of a switch structure TGSE, which represents the smallest data structure managed within the switch pool, and which is assigned to a transaction by a primitive of the transaction management system or the generation management system and into a transaction sheet TGL is set as an overlay structure.
  • a data field PATTERN represents a parameter for monitoring purposes, which indicates that the switch structure is linked to a complete memory block which has been assigned to the transaction by the data pool VLP.
  • a transaction identifier TA_ID which designates the transaction which has requested (assigned) the switch structure, and which identifies the data structure suspended on the switch structure, e.g. a data object reserved exclusively for the associated transaction.
  • a command identifier COM_ID and a logical key LOG_KEY represent protocol information per data object which is used for communication with the generic modules.
  • a backward reference PTR_BACK_REF which represents a pointer to an entry in a translator for the logical key, or in the case of a generation tree, a pointer to the previous switch structure.
  • a flag F distinguishes the two cases mentioned.
  • a pointer PTR_OLD_DATA which represents a pointer to the old image of a data object or, in the case of a generation tree, a pointer to the next switch structure.
  • the two cases mentioned are in turn distinguished by a flag F.
  • a pointer PTR_NEW_DATA which represents a pointer to a new image of a data object, with a flag F being shows whether the data of the new image should be loaded onto other sheet shapes.
  • a data field TGSE_L that represents the physical length of the data stored in a data field NEW_DATA.
  • a data field OLD_BLK_L that represents the physical length of the old memory block allocated by the data pool VLP.
  • a data field NEW_BLK_L that represents the physical length of the new memory block allocated by the data pool VLP.
  • a pointer PTR_NEXT_TGSE which represents a pointer assigned in the same transaction to the next switch structure.
  • a data field NEW_DATA which represents a data container for receiving the new data.
  • the semi-permanent logbook represents a table in which one line is reserved for each existing transaction identifier TA_ID of the switch pool.
  • the semi-permanent logbook represents a table for the management of transactions, which contains a current transaction identifier TA_ID_ACT in its header. The value of this current transaction identifier is assigned to each newly started transaction and then incremented.
  • the current Rapid transaction identification in the header is implemented as a cyclical counter.
  • a data field PROCGRP.ID which contains information about the process group that started the transaction.
  • a STATUS state field contains information about the state (phase) in which a transaction is located.
  • a transaction is essentially divided into three phases, namely a preparation and activation phase, both of which are under the control of the transaction management system and a generation phase which is under the control of the generation management system, and in which the new data is transported to its final storage locations in memory and on the disk.
  • the individual steps of the various phases mentioned are recorded as state information in the state field. This recording enables the consistency management system to react in a suitable manner to events which trigger a restart of the real-time system.
  • the start of a transaction is clearly marked by the assignment of a transaction identifier TA_ID.
  • the generation of a new data generation within the activation phase of a transaction also requires the assignment of a generation identifier, which is also uniquely identifiable. Since all actions carried out in the generation phase of the transaction are carried out on the basis of the generation identifier, an ⁇ emipermanent data structure, namely the area table SCOPE_TAB mentioned, must be present in order to identify the generation with the transaction to be able to link the identification and thereby be able to access the data newly introduced in a transaction.
  • the area table Another purpose of the area table is to record the entire area of data generations that is managed by the generation management system.
  • the transaction management system uses the area table to assign a generation identifier to a transaction. For this reason, the area table also contains a pool of generation identifications.
  • the entire range of generations that are recorded in the range table is described by a parameter GEN_ID-OLD, which points to the end of the range table and a parameter GEN_ID_NEW, which contains a pointer to the start of the range table.
  • the parameter GEN_ID-NEW also contains a pointer to the pool of generation IDs, which is implemented as a cyclic counter.
  • a procedure APPOINT_TAID evaluates the transaction identifier pool, assigns the current transaction identifier to the requested transaction and then increases the value of the current transaction identifier.
  • a procedure ALLOCTGL evaluates the ⁇ emipermanent header of the soft pool TGS_P, assigns the transaction
  • Transaction sheet too or represents a lack of resources then detects and triggers a transaction-priority processing with high priority.
  • a procedure ENTER_TG_LOGBOOk transfers transaction information, e.g. Information about the status of a transaction in the logbook TG_LOG.
  • a VERIFY-TAID procedure verifies the transaction identifier TA_ID, which the user of the procedure D0_TA, which will be explained in more detail later, has passed to the control system as a parameter in order to determine whether this transaction identifier is still recorded in the logbook.
  • a DETMINE_TA_STATE procedure determines the state of a transaction based on the corresponding entry in the log book.
  • An APPOINT.GENID procedure evaluates the generation identification pool, assigns a current generation identification and increments the current value of the current generation identification.
  • a procedure ALLOCTGSE represents a service procedure of the CTCC for the ADB. It enables a module instance of the application-specific data base ADB to be assigned to a transaction an ⁇ -permanent switch structure TGSE for transaction-controlled inputs.
  • the ALLOC_TGSE procedure includes the following activities:
  • a CONFIRM_TADATA procedure traverses the switch structure chain and informs the data pool VLP in the event of a connected memory block of the data pool using the CONFIRM-SE IZE procedure.
  • a DETMINE_TGSLNK procedure evaluates the TG.LOG log book and uses it to determine the soft TGS-LINK pointer.
  • a DETMINE.TGSEINFO procedure evaluates a switch structure TGSE and determines certain information, e.g. the transaction identifier TA_ID, or the type of linking of the switch structure from the data field PATTERN.
  • a DETMINE.OLDTAID procedure evaluates the log book and uses it to determine the smallest transaction ID TA_ID recorded in it.
  • a procedure ENTER_TGSHEADER transfers status information of a transaction, e.g. the information disk errors in the corresponding status field of the header of the switch pool TGS_P.
  • a procedure TA..ROLLBCKMEM enables a roll backward of transaction-controlled entries. This procedure carries out the following actions: It traverses the switch structure chain of a transaction
  • the TA.ROLLBCKMEM procedure is also used in the case of a disk error.
  • a procedure TA..ROLLFORWARD enables transaction-controlled entries to be continued (roll forward) in the event of recovery events and contains parts of the procedure DO_TA explained later.
  • the entry point into this contained procedure depends on the transaction status that existed when the recovery event occurred.
  • the DO_TADATA procedure causes the transaction data transferred to the access control system to be forwarded to the update entity UPDATE, both for storage in the NOTEBOOK notebook and on the DISK disk.
  • An input parameter TASK with the two possible values "TGSLEAF” or “VLP” determines whether the procedure works with the transaction data which are defined by the entry in the header of the transaction sheet or with those transaction data which are in a corresponding memory block in the data pool VLP stored, works.
  • Possible output parameters OUTPUT of the procedure mentioned are "disk error", "NO_SUCCESS” and "SUCCESS".
  • FIG. 12 shows the flow diagram of a procedure DO_TGSE_ENTRY.
  • This procedure runs through the turnout structure chain and transmits binding information that integrates a turnout structure into the data access path to the updating instance with the order for storage in the notebook. If necessary, it also causes storage on the disk with the call UPDATE: DISK.
  • the procedure has no input parameter and as output parameter the same parameters as the previous procedure.
  • the procedure also converts possible status information TA.TGSHPREP or TA_ TGSHSUCC into status information TA_DISKPREP.
  • FIG. 13 shows the flow diagram of a procedure START_TA.
  • This procedure opens a transaction, whereby it transfers the process group identification to the access control system as the input parameter. And as the output parameter receives the parameters TA_ID and / or "LACK OFF RESOURCES" shown in FIG. 13. The status information becomes "NO.TRANS" in the course of this procedure.
  • FIG. 14 shows the flow diagram of a procedure ABORT.TA.
  • This procedure enables the user to cancel a transaction that he has activated.
  • the user transfers the access control system to the transaction control associated with the transaction as an input parameter, whereupon the associated transaction is undone by the procedure.
  • the initial parameters of the procedure can again be seen in FIG. 14.
  • the possible status information "TA_STARTED” or “TA.NODISKNB” available at the beginning of the procedure is converted by the procedure into the status information "TA_ ABORTED".
  • the generation management system controls the read-oriented access to the data objects of the data management system.
  • the read-oriented access comprises a sequence of logically interconnected read requests. Within such a sequence it is ensured that a consistent set of data objects, i.e. a set of data objects that is valid with respect to a specific point in time is accessed, even if a transaction updates one or more of the accessed data objects in parallel. In order to ensure this simultaneity, the new and old image each data object is stored in parallel in the working memory as well as on the disk.
  • the generation identifier GEN-ID which is assigned to a transaction during the activation phase, is used by the generation management system in the generation phase of a transaction to record the new data generation generated by the transaction to identify clearly.
  • the generation tree 16 shows an exemplary generation tree for a specific data object.
  • the generation tree comprises three generations D1, D2 and D3.
  • the latest generation D3 is contained in a switch structure, while the oldest generation D1 is in its final position in the main memory.
  • the data access path to the generation tree is implemented via a translator structure in the form of a list, which is referred to below as the translator list TRL.
  • the record fields of the translator structure are controlled by the access control system via a logical index and hold a physical pointer to a switch structure or, if no generation tree exists, to the data object in the working memory.
  • the record feeders of the translator structure are referred to below as their data link functions according to their function.
  • the generation management system TMS (see FIG. 4) comprises a transaction post processing system that contains all of the data (input data) stored in the course of a transaction in the semi-permanent switch pool TGS_P transferred to their final storage locations in the working memory and on the disk.
  • the start of the transaction post-processing system therefore marks the beginning of the generation phase for the transaction associated with this data.
  • the transaction post-processing system at the same time permanently destroys the data of the oldest data generation which is present under these newly introduced data.
  • the start of the transaction post-processing system therefore marks the end of the generation phase for the transaction associated with this data.
  • the transaction-process processing system is technically implemented as an internal transaction of the access control system and is therefore synchronized and coordinated with other transactions.
  • the transaction-process-processing system is started for two different reasons and therefore has two different process priorities. If the transaction post-processing system is started in order to remedy a lack of resources in the TGS pool, it has a higher process priority than an administrative process. If the transaction post-processing system is started in order to transfer the data newly introduced by a transaction to its final storage location, it has the same process priority as an administration process. 17 shows the flowchart of the transaction post processing system, the terms occurring therein being explained in more detail below.
  • the read logbook SEQ.LOGBOOK shows the access data structure introduced in connection with the generation management system, the so-called read logbook SEQ.LOGBOOK, in which active reading sequences are recorded.
  • the reading log book also takes part in the time monitoring of reading sequences, since reading sequences that run too long represent a negative system influence. This participation consists in the time monitoring cyclically scanning the entries in the read log. If it detects a reading sequence that has exceeded a certain time limit, this reading sequence is discarded.
  • the reading log book contains a data field PROCGRP-ID that contains information about the process group that called the reading sequence. Like the corresponding field in the transaction log, this field serves to support recovery post-processing.
  • the reading log book further comprises a data field SEQ_STATUS, which indicates to the transaction-post-processing system a running active reading sequence and thereby excludes that a data object belonging to the generation identifier is physically deleted.
  • SEQ_STATUS indicates to the transaction-post-processing system a running active reading sequence and thereby excludes that a data object belonging to the generation identifier is physically deleted.
  • a VERIFY.GENID procedure verifies the generation identifier
  • a procedure ALLOC_SEQREC initially assigns a read sequence corresponding to the generation identifier to a read sequence in the read log book.
  • a procedure ENTER.SEQLOG transmits status information of the reading sequence in the reading log book.
  • a DETMINE_GENIDOLD procedure evaluates the area table and determines the oldest generation identifier GEN_ID_OLD.
  • a TRANS-GENTAID procedure uses the area table to determine the transaction identifier that corresponds to the generation identifier transferred to this procedure.
  • a procedure POSTPROCTGSE of the transaction-post-processing system TAPP passes through the switch structure chain of a transaction and carries out the following activities:
  • a procedure POSTPROC-HEADER of the transaction-post-processing system which comprises the following activities: it changes the transient status information in the header of the switch pool to the value "TA_CLOSED",
  • a GEN-ROLLBCK procedure enables a roll backward of transactions in the generation phase and carries out the following actions:
  • the flow diagram of the END_GETSEQUENCE procedure which ends a reading sequence and releases all data objects associated with the generation identification of the reading sequence for the transaction post-processing by changing the parameter SEQ_STATUS to the value "FREE".
  • the input parameter of this procedure is the parameter GEN_ID.
  • the output parameter of this procedure is a message parameter with the messages "out of scope” or "accepted”.
  • the package Eions management system essentially comprises two procedures, namely a procedure TA_CONCTRL to handle the access collisions in the phase of a transaction controlled by the transaction management system and a procedure GEN_CONCTRL to deal with the access collisions in the generation management System to control the controlled phase of a transaction.
  • a data link field contains, in addition to the pointer field, an access field in which a transaction stores its transaction identifier if the access field has not yet been closed, i.e. if no other transaction identifier is already stored in the access field.
  • the link between the switch structure and the data access path is then effected by the storage of the physical pointer on the switch structure.
  • a switch structure which is to be linked to a specific data link field in the course of a transaction comes into conflict with one another if another active transaction has already occupied the access field of this data link field.
  • the coordination of this conflict is regulated as follows:
  • FIG. 22 shows a flowchart of the GEN_CONCTRL procedure, which is embedded in the POSTPROCR_TGSE procedure of the transaction-post-process-processing system and conflicts between transaction-transaction-processing system and a read sequence of a transaction in the generation phase . More precisely, the procedure GEN_CONCTRL prevents a data generation from being deleted if a read sequence wants to access this data generation in the case of a low-priority transaction post-processing. In contrast to this, in the case of a high-priority transaction process process, in the event that there is a lack of resources for the access control system, the reading sequence is discarded and the data generation is deleted.
  • Input parameters of the GET procedure are an identifier of the read action and a logical key which leads through the data access path to the data object.
  • the transaction identifier is a transaction identifier TA_ID if the GET procedure is used within a transaction. In the other case, namely if the procedure GET is used within a read sequence, the identifier is a generation identifier GEN_ID.
  • Initial parameters of the GET procedure are the data object and a message parameter for returning control messages.
  • the data access path is run through using lists of the logical key.
  • 24 shows the exemplary structure of a data access path which comprises several lists and is stored in the user-independent data module VLP.
  • the data access path comprises a data block list UBL, the list elements of which represent pointers to data blocks ÜB, and within a data block ÜB an object class list OCL and data object list DOL.
  • the logical key comprises indexes of the lists mentioned, namely the indexes UBL_IX, OCL_IX and DOL_IX, by means of which the pointer to a data object OCI or a switch structure TGSE can finally be determined.
  • the GET procedure runs through the data access path by calling the RD_BLK procedure, which is implemented in the user-independent central data pool VLP.
  • This procedure returns the physical pointer to a data object list DOL as a return value.
  • this pointer is only used in the activation phase following the preparation phase of the transaction in order to carry out the actual access.
  • the ACCESS_OCI procedure is called with the parameters "pointer to the data object list DOL" and "DOL_IX". This procedure examines i.a. the header of the DOL and determines whether the transferred parameter "DOL_IX" is a valid index.
  • the list field of the list DOL corresponding to the index DOL_IX is analyzed. It is examined whether the identifier ID stored in the access field (closure field) of the list field is a transaction identifier or a generation identifier. This is represented in FIG. 23 by a branch block.
  • the generation tree connected to the data access path is evaluated on the basis of the EVAL_GENTREE procedure and then the the physical pointer corresponding to the generation identifier is returned to the data object.
  • the ALLOC_TGSE procedure is called, which prepares a subsequent write action by means of a SET procedure, and locks the data object with respect to other transactions. This has the further consequence that during the activation phase of the transaction the transaction-post-processing cannot carry out any actions with regard to this data object.
  • a user-specific data module GMI further comprises a procedure SET which modifies a data object within a transaction.
  • the input parameters of this procedure are a transaction identifier TA_ID, a logical key for guiding through the data access path and a pointer to the new data to be transferred, as well as a length specification of the new data.
  • Output parameter is a parameter for feedback.
  • the SET procedure includes data access which is carried out using the RD_BLK and ACCESS_OCI procedures.
  • the ALLOC_TGSE procedure contained in the CTCC is then called, which requests a new switch structure TGSE and copies the new data or the new data object into the switch structure. If the SET procedure has been prepared by the GET procedure, the aforementioned assignment of a new switch structure is omitted.
  • the user-specific data modules also include a procedure CREATE, which extends an object class by a data object, and a procedure DELETE, which reduces an object class by a data object.
  • a procedure CREATE which extends an object class by a data object
  • a procedure DELETE which reduces an object class by a data object.

Abstract

Datenverwaltungssystem von Realzeitsystemen sollen Anwendersystemen eine schnelle und konsistente On-Line Verwaltung verschiedener Datengenerationen zur Verfügung stellen. Diese Aufgabe wird erfindungsgemäß durch eine Zugriffs-Datenstruktur erreicht, die es einem Generationen-Management-System (GMS) ermöglicht, die Verwaltung verschiedener Datengenerationen auf der Basis derselben Datenobjekte durchzuführen, die vorher bereits von einem Transaktions-Management-System (TMS) zur Durchführung von Transaktionen verwendet wurden.

Description

Beschreibung
Datenverwaltungssystem eines Realzeitsystems
Datenverwaltungssysteme von Realzeitsystemen sollen ihren An¬ wendersystemen eine schnelle und sichere (konsistente) On¬ line-Verwaltung verschiedener Datengenerationen bieten.
Der Erfindung liegt die Aufgabe zugrunde, ein Datenverwal- tungssystem anzugeben, das die obengenannten Anforderungen erfüllt.
Diese Aufgabe wird durch ein Datenverwaltungssystem mit den Merkmalen nach Anspruch 1 gelöst.
Durch die funktionale Kopplung der Transaktionssteuerung mit der Generationenverwaltung über eine gemeinsam verwendete Zu¬ griffs-Datenstruktur zu den Datenobjekten des Datenverwal¬ tungssystems wird die Verwaltung verschiedener Datengenera- tionen auf der Basis derselben Datenobjekte, wie sie auch von dem Transaktionε-Management-System verwendet werden, durchge¬ führt. Dadurch wird eine schnelle und sichere Online-Verwal¬ tung ermöglicht.
Eine Ausführungsform der Erfindung ist durch Anspruch 2 ange¬ geben. Durch diese Ausführungsform werden die im Rahmen einer Transaktion erzeugten neuen Datenobjekte zu einer Datengene¬ ration zusammengefaßt und sind somit anhand einer GEN_ID ein¬ deutig nach ihrer Entstehungsreihenfolge identifizierbar. Da- durch ist es dem Generationen-Management-System bspw. mög¬ lich, eine nicht mehr benötigte Datengeneration gemeinsam, d.h. durch einen einzigen Löschauftrag, zu löschen.
Eine weitere Ausführungsform der Erfindung ist durch Anspruch 3 angegeben. Durch diese Ausführungsform wird die Durchfüh¬ rung von zu einer Transaktion parallelen Lesesequenzen ermög¬ licht. Eine Ausführungsform der Erfindung ist durch Anspruch 4 ange¬ geben. Durch diese Ausführungsform wird der Zugriff von zu einer Transaktion parallelen Transaktionen zu demselben Da- tenobjekt verhindert.
Eine weitere Ausführungsform der Erfindung ist durch Anspruch
5 angegeben. Durch die dynamische Zuordnung wird die Behand¬ lung von Datenobjekten verschiedener Granularität ermöglicht. Das heißt, daß eine TGSE sowohl einem Datenobjekt kleinster Granularität (Datenelemment) , als auch einem Datenobjekt grö¬ ßerer Granularität (Datengruppe) zugeordnet werden kann. Die genannte dynamische Zuordnungsbarkeit wird dadurch erreicht, daß die TGSE entweder dynamisch bei Bedarf erzeugt werden, oder einem gemeinsamem Pool entnommen werden.
Eine weitere Ausführungsform der Erfindung ist durch Anspruch
6 angegeben. Durch diese Ausführungsform können die TGSE vom Transaktions-Management-System nach ihrer Entstehungsreihen- folge zu einem Generationenbaum verkettet werden, der vom Ge¬ nerationen-Management-System anschließend verwaltet wird. Diese Ausführungsform setzt die dynamische Zuordnung der TGSE vorraus.
Im folgenden wird ein Ausführungsbeispiel der Erfindung an¬ hand der Zeichnung näher erläutert.
In der Zeichnung repräsentieren die Pfeile zwischen den Sy¬ stem-Blöcken eine funktionale Beziehung (z.B. einen Prozedur- aufruf, wobei der Kopf eines Pfeils auf die aufgerufene Pro¬ zedur zeigt) .
Fig. 1 und 2 zeigen die Struktur eines erfindungsgemäßen Da¬ tenverwaltungssystems EDB, auf das verschiedene Anwendungen APPL zugreifen können. Das Datenverwaltungssystem besteht aus zwei Schichten, näm¬ lich einer anwendungsspezifischen Systemschicht, die im fol¬ genden als applikationsspezifische Datenbasis ADB bezeichnet wird, und einer anwendungsunabhängigen Systemschicht, die im folgenden als generische Datenbasis GDB bezeichnet wird.
Die generische Datenbasis GDB umfaßt zentrale und lokale Funktionen, wobei die zentralen Funktionen in einem zentralem Steuerungssystem CU und die lokalen Funktionen in generischen Modulen GM realisiert sind.
Das zentrale Steuerungssystem CU enthält ein zentrales Zu- griffssteuerungssystem CTCC, das Zugriffe (Einzelzugriffe oder ZugriffSequenzen) zentral steuert, allgemeine Zugriffs- algorithmen ALG, ein Sicherungssystem VSI, das die Schnitt¬ stelle zu einem Hintergrundspeicher zur Sicherung der Anwen¬ derdaten realisiert, einen Datenpool VLP zur Verwaltung von Daten mit variabler Länge und ein zentrales Verteilungssystem DDFC, das der Verteilung von aktualisierten Anwenderdaten auf die verschiedenen Prozessoren des Realzeitsystems dient.
Ein generisches Modul GM stellt ein Definitionsmodul zur Be¬ schreibung eines Daten-Containers dar, der Datenstrukturen zum Speichern der Anwenderdaten sowie die dazu benötigten Zu- griffsstrukturen, d.h. Adressierungsverfahren und elementare Zugriffsprozeduren, enthält. Darüberhinaus enthalten die ge¬ nerischen Module zusätzliche Strukturen zur Unterstützung des zentralen Funktionensystems, d.h. Strukturen zur Unterstüt¬ zung der Koordination und KonsistenzSicherung (lokales Zu- griffssteuerungsSystems CTCL) , sowie Strukturen zur Unter¬ stützung der Verteilung der Anwenderdaten auf verschiedene Plattformen (lokales Datenverteilungssystem DDFL) . Die Be¬ schreibung der genannten Strukturen im generischen Modul er¬ folgt dabei in einer vom Anwender unabhängigen Weise, d.h. in einer vom Daten-Layout der Datenstrukturen unabhängigen Weise. Unterschiedliche Typen von generischen Modulen werden durch Kombination von Bausteinen (z.B. lokales Zugriffssteuerungs¬ system CTCL, lokales Verteilungssystem DDFL sowie hierzu not¬ wendige zusätzliche Datendefinitionen, verschiedene Adressie- rungsverfahren) erzeugt. Die Varianten werden durch die An¬ forderungen bestimmt, die sich aus der Datenmodellierung der entsprechenden Anwendung ergeben.
Jedes generische Modul enthält einen Satz von elementaren Zu- griffsprozeduren, die die Steuerung eines Einzelzugriffs be¬ treffen. Dieser Satz umfaßt eine Prozedur GET zum Lesen von Anwenderdaten, eine Prozedur SET zum Modifizieren von Anwen¬ derdaten sowie Prozeduren CREATE und DELETE zum Erzeugen bzw. Löschen von Datenelementen des Anwenders. Ein Zugriff auf die Daten eines Anwenders ist nur über diese speziellen Zugriffs¬ prozeduren möglich (Datenkapselung) . Daten mit entsprechender Persistenzanforderung werden im Core-Image-Format auf einem Hintergrundspeicher gesichert. Dadurch wird gewährleistet, daß nach einem Wiederanlauf des Vermittlungsrechners mit zu- gehörigem Ladevorgang die aktuellen Daten schnellstmöglich zur Verfügung stehen.
Die applikationsspezifische Datenbasis ADB umfaßt Views und Modulinstanzen, wobei die Modulinstanzen durch Instantiierung aus den generischen Modulen erzeugt werden.
Durch die genannte Instantiierung werden die Daten-Container (generischen Module) mit bestimmten Daten-Deklarationen ini¬ tialisiert, wodurch die Datenstrukturen und die Zugriffsalgo- rithmen auf diese Datenstrukturen in Beziehung zueinander ge¬ setzt werden. Die Views bilden die Schnittstelle zu der aktu¬ ellen Anwendung APPL. Sie repräsentieren damit das logische Bild des konzeptionellen Datenmodellε dieser Anwendung.
Das Zugriffssteuerungssystem steuert den Zugriff von Anwen¬ dern auf das Datenverwaltungssystem EDB und stellt dabei si¬ cher, daß ein Aktualisierungsvorgang die Daten im Datenver- waltungssystem von einem konsistenten Ausgangszustand in ei¬ nen konsistenten Endzustand überführt. Um diese Konsistenz sicherzustellen, behandelt das Zugriffssteuerungssystem Zu¬ griffssequenzen (Transaktionen oder Lesesequenzen) in einer ganzheitliehen (atomaren) Weise, d.h. eine Transaktion wird bspw. entweder ganzheitlich durchgeführt oder ganzheitlieh zurückgewiesen.
Darüberhinaus koordiniert das Zugriffssteuerungsεystem den gleichzeitigen Zugriff von zueinander parallelen Zugriffsse¬ quenzen.
Das Zugriffssteuerungssystem umfaßt das CTCC, welches für den Anwender solche Steuerungsaufträge (z.B. START_TA, DO_TA, ABORT_TA) durchführt, die die Steuerung einer Zugriffssequenz in ihrer Gesamtheit betreffen.
Der zentrale Datenpool VLP verwaltet semipermanente und tran- siente Daten von variabler Länge. Er beinhaltet sowohl die Daten als auch einen Satz von Primitiven, um die von ihm be¬ herbergten Daten abzuspeichern und zu manipulieren.
Alle vom zentralen Datenpool verwalteten Daten werden durch den Datenpool eingekapselt. Alle Zugriffe auf diese Daten können also nur über die genannten Primitiven erfolgen. Die genannten Modulinstanzen können vom Datenpool einen Block be¬ liebiger Länge reservieren lassen, wobei jeder reservierte Datenblock durch einen bei seiner Reservierung zugeordneten logischen Schlüssel identifiziert wird.
Die generischen Zugriffsalgorithmen ALG umfassen Funktionen, die allen generischen Modulen gemeinsam sind, nämlich zum ei¬ nen Algorithmen zur logischen Organisation der Datenhaltung (z.B. linked list, binary tree) , zum anderen Mechanismen zur physikalischen Speicherung der Daten, d.h. datenstrukturunab- hängige Wege durch datenbasisinterne Verwaltungs- bzw. Zu- griffsstrukturen. Die generischen Zugriffsalgorithmen werden ausschließlich von den generischen Modulen aufgerufen.
Das DDFC steuert den Transfer von Anwenderdaten von einer Plattform (Prozessor) zu anderen Plattformen (Prozessoren) und gewährleistet dabei die Datenkonsistenz zwischen ver¬ schiedenen Plattformen (Prozessoren) . Das DDFC wird von einem DDFL eines Anwendermoduls dynamisch aufgerufen.
Ein generisches Modul dient, wie bereits erwähnt, als ein Da¬ ten-Container, der Datenstrukturen sowie für diese Daten¬ strukturen spezifische Zugriffsalgorithmen in einer anwen¬ dungsunabhängigen Weise beschreibt, d.h. in einer vom Daten- Layout unabhängigen Art und Weise. Ein generisches Modul um- faßt einen Satz von Zugriffsprozeduren zum Datenverwaltungs¬ system, die es der jeweiligen Anwendung zur Verfügung stellt, um dadurch einen lesenden oder schreibenden Zugriff zu den in der generischen Datenbasis GDB enthaltenen Daten zu realisie¬ ren.
Aufgrund der internen Architektur eines generischen Moduls, die zwischen Datenstruktur-spezifischen Teilen und allgemei¬ nen Teilen des Datenzugriffs und der Datenbehandlung unter¬ scheidet, können allgemeine Funktionen als generische Algo- rithmen ALG deklariert werden, die von jedem generischen Mo¬ dul benutzt werden können, da sie in dem Zentralmodul CM der generischen Datenbasis enthalten sind. Darüberhinaus benützen die generischen Module andere allgemeine Funktionen, die vom zentralen Zugriffssteuerungssystem CTCC und dem Datenpool VLP zur Verfügung gestellt werden.
Ein Hauptzweck, der mit der Einführung von generischen Modu¬ len verfolgt wird ist die Wiederverwendbarkeit und Wiederer¬ setzbarkeit von Software. Die generischen Module bilden eine Bibliothek (Library) , aus der anwendungsspezifische Objekt¬ klassen durch Instantiierung erzeugt^ werden können,, d.h. durch das Ersetzen von allgemeinen Datenlayout-Informationen (Platzhaltern, in CHILL z.B. ANY_ASSIGN) durch spezifische
Layout-Informationen. Die Anwendung kann geeignete generische
Module auswählen, diese instantiieren und die instantiierten
Module zu einem View bzw. mehreren Views kombinieren.
Durch die Einfügung der Anwendungsprozedurschicht VIEW zwi¬ schen Anwendung und Anwendermodul erreicht man die Unabhän¬ gigkeit der jeweiligen Anwendung von den logischen Daten- εtrukturen. Mit Hilfe einer Anwendungsprozedur werden Zugrif- fe auf eine oder mehrere Anwendermodule durchgeführt, wobei ein Anwendermodul jeweils eine Objektklasse verwaltet. Eine Anwendungsprozedur enthält als Parameter die gewünschten Attribute des jeweiligen Datenobjekts, wobei es sich bei die¬ sen Parametern um Rückgabeparameter handelt, die der Applika- tion nach Ausführung der Anwenderprozedur zurückgegeben wer¬ den. Durch die Anwendungsprozedur wird der Anwendung somit eine eigene Sichtweite auf die gespeicherten Anwendungsdaten bereitgestellt. Änderungen der logischen Datenstrukturen ha¬ ben somit keine Auswirkungen auf die Anwendungen.
Eine Anwendung bzw. ein Anwender verwendet zur Verwaltung seiner Anwenderdaten ausschließlich die Anwendungsprozeduren VIEW. Für die konsistente Änderung abhängiger Daten wird eine entsprechende Folge von Anwenderprozeduraufrufen durch Be- fehle an das zentrale Zugriffssteuerungssystem als Transak¬ tion gekennzeichnet. Die Durchführung der Transaktion sowie die Sicherung der Daten auf dem Hintergrundεpeicher und die Verteilung der Daten erfolgt in eigenεtändiger Weise durch das Datenverwaltungεεystem und ist somit vollständig unsicht- bar für den Anwender.
Fig. 3 zeigt die Vorbereitungsphase und die Aktivierungsphase einer Transaktion.
In der vom Anwender gesteuerten Vorbereitungsphase wird die Transaktion Schritt für Schritt aufgebaut, indem vom Anwender nacheinander die Zugriffsprozeduren (SET, GET, usw.) für Ein¬ zelzugriffe aufgerufen werden. Innerhalb einer Transaktion können grundsätzlich beliebig viele Einzelzugriffe durch Auf¬ ruf der entsprechenden Zugriffsprozeduren initiiert werden.
Die Vorbereitungsphase wird durch die Prozedur START_TA ge¬ startet und durch die Prozedur DO_TA beendet. Die Prozedur START_TA ordnet der Transaktion eine Transaktionskennung TA_ID zu und übergibt sie dem Anwender. Der Anwender verwen- det diese TA_ID dann als Eingangsparameter beim Aufruf der Zugriffsprozeduren für Einzelzugriffe.
In der Vorbereitungsphase werden die Aufrufe der Zugriffspro¬ zeduren aufgezeichnet und eventuelle Änderungen der vom Zu- griff betroffenen Daten vorbereitet. In der Vorbereitungspha¬ se hat der Anwender die Möglichkeit, die Transaktion durch den Aufruf der Prozedur ABORT_TA zu verwerfen.
Durch den Aufruf der Prozedur DO_TA wird gleichzeitig die Ak- tivierungsphase gestartet, die ausschließlich vom zentralen Zugriffssteuerungssystem gesteuert wird und deshalb unabhän¬ gig von Anwenderaufrufen abläuft. In der Aktivierungsphase können somit keine weiteren Aufrufe für Einzelzugriffe be¬ rücksichtigt werden.
In der Vorbereitungsphase wird die Koordination einer Trans¬ aktion durchgeführt, d.h. alle Kollisionsfälle mit anderen parallel Transaktionen werden identifiziert und koordiniert. Die Koordinierung erfolgt dabei derart, daß solche Transak- tionen, die früher gestartet wurden, fortgeführt werden dür¬ fen, wogegen andere parallele Transaktionen zurückgewiesen werden, indem eine entsprechende negative Rückmeldung an den Anwender zurückgegeben wird. Da alle Kollisionsfälle somit in der Vorbereitungsphase gelöst werden, können Transaktionen in der Aktivierungsphase unabhängig voneinander durchgeführt werden. Fig. 4 zeigt die Struktur des zentralen Zugriffssteuerungssy¬ stems CTCC. Das zentrale Zugriffssteuerungssystem CTCC umfaßt ein Transaktions-Management-System TMS, ein Generationen-Ma¬ nagement-System GMS, ein Resourcen-Management-System RMS und ein Kollisions-Management-System CMS.
Das Transaktions-Management-System TMS steuert den transakti- onsorientierten Zugriff auf die Datenobjekte OCI des Daten¬ verwaltungssystems.
Das Generationen-Management-Syεtem GMS verwaltet die im Rah¬ men von Transaktionen erzeugten Datengenerationen anhand ei¬ ner vom Transaktions-Management-System während der Aktivie¬ rungsphase einer Transaktion vergebenen Generationenkennung GEN_ID. Diese Verwaltung umfaßt das Aktualisieren einer neu erzeugten Datengeneration, d.h. das Transferieren der neuen Datengneration auf ihre endgültigen Speicherplätze im Ar¬ beitsspeicher und/oder auf der Disk. Darüber hinaus umfaßt die genannte Verwaltung die Steuerung von Lesesequenzen (Folgen von logisch zusammengehörigen Lesezugriffen auf die Datenobjekte des Datenverwaltungssystems) .
Durch diese Art der Verwaltung wird es ermöglicht, daß eine Gruppe von Datenobjekten ein und derselben Generation im Rah- men einer Lesesequenz gelesen werden kann, während parallel dazu eine Transaktion stattfindet.
Das Resourcen-Management-System RMS verwaltet die Zugriffs- Datenstrukturen, die beim Zugriff des Transaktions-Manage¬ ment-Systems und/oder des Generationen-Management-Systems verwendet werden.
Das Kollisions-Management-System CMS koordiniert schreibende Zugriffe auf ein und dasselbe Datenobjekt, die durch pa¬ rallele Transaktionen ausgelöst werden und verhindert, daß die älteste Datengeneration gelöscht wird, während gleichzei- tig eine Lesesequenz einen lesenden Zugriff auf Datenobjekte dieser Datengeneration durchführen will.
Das RMS umfaßt als größte Datenstruktur einen Weichenpool TGS_POOL, der sowohl vom Transaktions-Management-System TMS, als auch vom Generationen-Management-System verwendet wird. Der Weichenpool dient dazu, vom Transaktions-Management-Sy¬ stem TMS im Rahmen einer Transaktion entgegengenommene neue Daten (transaktionsorientierte Eingaben) aufrechtzuerhalten (zwischenzuspeichern) , bis sie an ihren endgültigen Speicher¬ plätzen im Speicher und auf der Disk durch das Generationen- Management-System abgelegt worden sind.
Das RMS umfaßt des weiteren ein Logbuch TG_LOG, das eine ge- eignete Verwaltung der Transaktionen ermöglicht, eine Be¬ reichstabelle SCOPE_TAB, die zur Verwaltung der verschiedenen Datengenerationen dient, und als kleinste administrierbare Datenstruktur die bereits genannte Weichenstruktur TGSE.
Fig. 5 zeigt die Architektur des Weichenpoolε TGS_POOL.
Die Architektur des Weichenpools umfaßt 10 Transaktionsblät¬ ter TL mit entsprechenden Headern 0 bis 10. Daraus ergibt εich, daß daε Tranεaktions-Management-System 10 Transaktionen in paralleler Weiεe unterεtützt, da jedeε Tranεaktionεblatt TL auεεchließlich für eine beεtimmte Tranεaktion reεerviert wird, indem eine zugeordnete Tranεaktionεkennung TA_ID in das entsprechende Datenfeld des zugehörigen Headerε eingetragen wird. Ein zusätzliches elftes Transaktionεblatt ist vorgese- hen, um eε einer aktiven Tranεaktion zu ermöglichen in ihrer Auεführung sogar dann fortzufahren, wenn ihr zugehöriges Tranεaktionsblatt mangels ausreichend verfügbarem Speicher (angezeigt durch ein Datenfeld FREE_MEMORY innerhalb des Hea¬ ders) kurz läuft.
Damit ein Transaktionεblatt vom Reεourcen-Management-Syεtem zur Verfügung geεtellt werden kann, müεεen drei Bedingungen erfüllt sein. Als erste Bedingung muß der freie Speicherplatz des Heapε, der in einem Datenfeld FREE_MEMORY deε Headerε an¬ gezeigt wird über einer beεtimmten Schwelle liegen. Alε zwei¬ te Bedingung, darf ein Datenfeld TA_ID deε Headerε keinen Eintrag aufweiεen. Alε dritte Bedingung muß ein Datenfeld STATE des Headers, das den Zustand einer Transaktion anzeigt, den Zustand "frei" anzeigen.
Der Dateninhalt des Datenfeldes STATE ist ein transienter Pa- rameter innerhalb des semipermanenten Transaktionsblatteε, der notwendig ist, um ein Transaktionsblatt während einer Aufdatierungsphase weiterhin zu reservieren, obwohl die semi- permanten Parameter FREE_MEMORY und TA_ID bereits die Wieder¬ verwendbarkeit des Transaktionsblatteε für andere Transaktio- nen anzeigen.
Fig. 6 zeigt die Architektur eines Transaktionsblattes, ins- beεondere die im Header deε Tranεaktionεblatteε TGL enthalte¬ nen Datenfelder.
Ein Datenfeld BEGIN_USED_AREA zeigt den Beginn deε Speicher¬ bereichs an, der vom Transaktionεblatt TGL zur Speicherung der Input-Daten einer Tranεaktion beanεprucht wird. Ein Da¬ tenfeld END_USED_AREA zeigt daε Ende deε genannten Speicher- bereichs an. Das Datenfeld END_USED_AREA zeigt gleichzeitig den Beginn des Speicherbereichs an, der von einem weiteren TGL beansprucht werden kann.
Ein Datenfeld LENGTH_USED_AREA beinhaltet einen redundanten Parameter für Überwachungszwecke, der die Differenz des Spei¬ chers zwischen dem Inhalt des Datenfelds BEGIN_USED_AREA und des Datenfelds END_USED_AREA anzeigt.
Ein Datenfeld END_UPDATED_AREA zeigt schließlich daε omen- tane Ende deε von der Tranεaktion bereitε auf die Diεk über¬ tragenen Speicherbereichs an. Fig. 7 zeigt den Aufbau einer Weichenεtruktur TGSE, die die kleinste innerhalb des Weichenpools verwaltete Datenstruktur darstellt, und die durch eine Primitive des Transaktionε-Ma¬ nagement-Syεtemε oder des Generationen-Management-Systems ei- ner Transaktion zugeordnet wird und in ein Transaktionsblatt TGL als eine Overlay-Struktur gesetzt wird.
Ein Datenfeld PATTERN stellt einen Parameter für Überwa¬ chungszwecke dar, der anzeigt, daß die Weichenstruktur mit einem kompletten Speicherblock verknüpft ist, der der Trans¬ aktion durch den Datenpool VLP zugeordnet worden ist.
Eine Transaktionskennung TA_ID, die diejenige Transaktion be¬ zeichnet, die die Weichenstruktur angefordert (zugeordnet) hat, und die die an der Weichenstruktur aufgehängte Daten¬ struktur, z.B. ein Datenobjekt, exklusiv für die zugehörige Tranεaktion reεerviert.
Eine Komandokennung COM_ID und ein logiεcher Schlüεεel LOG_KEY repräεentieren Protokollinformationen pro Datenob¬ jekt, die zur Kommunikation mit den generischen Modulen die¬ nen.
Eine Rückwärtsreferenz PTR_BACK_REF, die einen Zeiger zu ei- nem Eintrag in einer Obersetzereinrichtung für den logiεchen Schlüssel, oder im Falle eines Generationenbaums einen Zeiger zur vorherigen Weichenstruktur repräsentiert. Ein Flag F un- terεcheidet die beiden genannten Fälle.
Einen Zeiger PTR_OLD_DATA, der einen Zeiger zu dem alten Bild eineε Datenobjektε, oder im Fall eineε Generationenbaumeε ei¬ nen Zeiger zur nächsten Weichenstruktur darstellt. Die beiden genannten Fälle werden wiederum durch ein Flag F unterschie¬ den.
Einen Zeiger PTR_NEW_DATA, der einen Zeiger zu einem .neuen Bild eines Datenobjekts repräsentiert, wobei ein Flag F an- zeigt, ob die Daten des neuen Abbilds auf andere Blattformen niedergeladen werden sollen.
Ein Datenfeld TGSE_L, daε die phyεikaliεche Länge der in ei¬ nem Datenfeld NEW_DATA geεpeicherten Daten repräεentiert.
Ein Datenfeld OLD_BLK_L, daε die phyεikaliεche Länge deε vom Datenpool VLP zugeordneten alten Speicherblockε repräεen¬ tiert.
Ein Datenfeld NEW_BLK_L, daε die physikalische Länge des durch den Datenpool VLP zugeordneten neuen Speicherblocks re¬ präsentiert.
Ein Zeiger PTR_NEXT_TGSE, der einen in derselben Transaktion zugeordneten Zeiger zu der nächεten Weichenεtruktur repräεen¬ tiert.
Ein Datenfeld NEW_DATA, daε einen Datencontainer zur Aufnahme der neuen Daten repräεentiert.
Mit der Beεchreibung der Weichenstruktur TGSE anhand von Fig. 7 ist die Beschreibung des semipermanenten Weichenpools TGS_POOL abgeschloεsen und es wird nunmehr mit der Beschrei- bung einer weiteren Datenstruktur des RMS, dem sog. Logbuch TG_LOG fortgefahren.
Fig. 8 zeigt die Struktur des Logbuchs TG_LOG zur Verwaltung von Tranεaktionen. Daε semipermanente Logbuch repräsentiert eine Tabelle, in der für jede vorhandene Transaktionskennung TA_ID des Weichenpools jeweils eine Zeile reεerviert iεt.
Daε εemipermanente Logbuch repräεentiert eine Tabelle zur Verwaltung von Tranεaktionen, die in ihrem Header eine aktu- eile Tranεaktionskennung TA_ID_ACT beinhaltet. Der Wert die¬ ser aktuellen Transaktionskennung wird jeder neugestarteten Transaktion zugeordnet und daraufhin inkrementiert. Die aktu- eile Transaktionskennung im Header ist als zyklischer Zähler implementiert.
Im folgenden werden die Felder einer beispielhaften Zeile des Logbuchε näher erläutert.
Ein Datenfeld PROCGRP.ID, daε Informationen über die Proze߬ gruppe, die die Tranεaktion geεtartet hat, beinhaltet.
Ein Zuεtandεfeld STATUS beinhaltet Informationen über den Zu- εtand (Phase), in der sich eine Transaktion befindet. Eine Transaktion ist im wesentlichen in drei Phasen unterteilt, nämlich eine Vorbereitungs- und Aktivierungsphaεe, die beide unter der Kontrolle des Transaktionε-Management-Syεtemε ste- hen und einer Generationenphase, die unter der Kontrolle des Generationen-Management-Systems steht, und in der die neuen Daten an ihre endgültigen Speicherplätze im Speicher und auf der Platte transportiert werden. Die einzelnen Schritte der genannten verεchiedenen Phaεen werden alε Zuεtandεinformatio- nen im Zuεtandsfeld aufgezeichnet. Diese Aufzeichnung ermög¬ licht dem Konεiεtenz-Management-Syεtem, in geeigneter Weiεe auf Ereigniεεe, die einen Wiederanlauf des Realzeitsystemε auεlöεen, zu reagieren.
Fig. 9 zeigt die Struktur der Bereichεtabelle SCOPE.TAB, de¬ ren Zweck im folgenden näher erläutert wird.
Der Beginn einer Tranεaktion wird in eindeutiger Weise durch die Vergabe einer Transaktionεkennung TA_ID markiert. Der Er- zeugung einer neuen Datengeneration innerhalb der Aktivie¬ rungsphase einer Transaktion erfordert darüber hinaus die Vergabe einer Generationenkennung, die ebenfalls in eindeuti¬ ger Weise identifizierbar ist. Da alle in der Generationen- phaεe der Tranεaktion auεgeführten Aktionen anhand der Gene- rationenkennung durchgeführt werden, muß eine εemipermanente Datenstruktur, nämlich die genannte Bereichstabelle SCOPE_TAB vorhanden εein, um die Generationenkennung mit der Tranεakti- onεkennung verknüpfen zu können und dadurch auf die in einer Tranεaktion neu eingeführten Daten zugreifen zu können.
Ein weiterer Zweck der Bereichεtabelle iεt eε, den geεamten Bereich von Datengenerationen aufzuzeichnen, der von dem Ge¬ nerationen-Management-Syεtem verwaltet wird. Daε Tranεakti¬ onε-Management-Syεtem benützt die Bereichεtabelle, um einer Tranεaktion eine Generationenkennung zuzuordnen. Auε dieεem Grund enthält die Bereichεtabelle außerdem einen Pool von Ge- nerationenkennungen.
Der gesamte Bereich von Generationen, die in der Bereichsta¬ belle aufgezeichnet werden, wird durch einen Parameter GEN_ ID-OLD beschrieben, der auf das Ende der Bereichstabelle zeigt und einen Parameter GEN_ID_NEW, der einen Zeiger auf den Beginn der Bereichstabelle beinhaltet. Der Parameter GEN_ ID-NEW beinhaltet deε weiteren einen Zeiger auf den Pool der Generationenkennungen, welcher alε zykliεcher Zähler imple¬ mentiert iεt.
Im folgenden werden die im RMS enthaltenen Reεourcenprimiti- ven, die eine Shell um die Zugriffε-Datenεtrukturen deε Zu- griffεεteuerungεεyεtemε CTCC bilden und dieεe Datenεtrukturen für alle anderen funktionalen Blöcke deε Zugriffεsteuerungs- εyεtemε tranεparent machen, näher erläutert. Die Verwendung dieεer Prozeduren wird durch Flußdiagramme in den folgenden Figuren näher erläutert.
Eine Prozedur APPOINT_TAID wertet den Tranεaktionεkennungen- Pool auε, ordnet der angeforderten Tranεaktion die aktuelle Tranεaktionskennung zu und erhöht anschließend den Wert der aktuellen Tranεaktionεkennung.
Eine Prozedur ALLOCTGL wertet den εemipermanenten Header deε weichen Pools TGS_P aus, ordnet der Transaktion ein
Transaktionsblatt zu oder stellt einen Mangel an Resourcen feεt und löεt daraufhin ein Tranεaktionε-Poεt-Proceεεing mit hoher Priorität auε.
Eine Prozedur ENTER_TG_LOGBOOk tranεferiert Tranεaktionsin- formationen, z.B. Informationen über den Status einer Tran¬ saktion, in daε Logbuch TG_LOG.
Eine Prozedur VERIFY-TAID verifiziert die Tranεaktionεkennung TA_ID, die vom Anwender der Prozedur D0_TA, die εpäter näher erläutert wird, dem Steuerungεεyεtem alε Parameter übergeben worden ist, um festzuεtellen, ob diese Transaktionεkennung im Logbuch immer noch aufgezeichnet iεt.
Eine Prozedur DETMINE_TA_STATE beεtimmt den Zuεtand einer Tranεaktion anhand deε entsprechenden Eintrags im Logbuch.
Eine Prozedur APPOINT.GENID wertet den Generationenkennungs- Pool auε, ordnet eine aktuelle Generationenkennung zu und in- krementiert den momentanen Wert der aktuellen Generationεken- nung.
Eine Prozedur ALLOCTGSE repräεentiert eine Dienεtprozedur deε CTCC für die ADB. Sie ermöglicht eε einer Modulinεtanz der applikationεεpezifiεchen Datenbaεiε ADB, einer Tranεak- tion eine εemipermanente Weichenstruktur TGSE für transakti- onεgeεteuerte Eingaben zuzuweisen. Die Prozedur ALLOC_TGSE umfaßt dabei folgende Aktivitäten:
- Die Überprüfung des von der Modulinstanz übergebenen Satzeε von Eingabeparametern - Die Überprüfung von verfügbaren Zugriffε-Datenεtrukturen, εowie daε Aufrufen eineε hoch prioriεierten Tranεaktions- Poεt-Proceεεingε, fallε keine auεreichende Speicherkapazi¬ tät verfügbar iεt
- Das Kopieren der neuen Daten in die zugewiesene Reichen- Struktur und das Einfügen der Weichenstruktur in die zuge¬ hörige Weichenεtruktur-Kette - Daε Aufrufen einer εpäter zu erläuternden Prozedur TA_ CONTRL deε Kolliεionε-Management-Syεtemε und im Falle kei- neε Konfliktes das Einfügen der genannten Weichenstruktur in den Datenzugriffspart des betreffenden Datenobjekts.
Eine Prozedur CONFIRM_TADATA durchεchreitet die Weichenεtruk- tur-Kette und informiert den Datenpool VLP im Falle eineε verbundenen Speicherblockε deε Datenpoolε mit Hilfe der Pro¬ zedur CONFIRM-SE IZE.
Eine Prozedur DETMINE_TGSLNK wertet daε Logbuch TG.LOG auε und bestimmt daraus den weichen Zeiger TGS-LINK.
Eine Prozedur DETMINE.TGSEINFO wertet eine Weichenstruktur TGSE auε und beεtimmt darauε beεtimmte Informationen, z.B. die Tranεaktionskennung TA_ID, oder die Art der Verknüpfung der Weichenstruktur aus dem Datenfeld PATTERN.
Eine Prozedur DETMINE.OLDTAID wertet das Logbuch aus und be- stimmt daraus die kleinεte darin aufgezeichnete Tranεaktionε- kennung TA_ID.
Eine Prozedur ENTER_TGSHEADER überträgt Statusinformationen einer Transaktion, z.B. die Information Disk-Fehler in das entεprechende Statuε-Feld deε Headerε deε Weichenpoolε TGS_P.
Eine Prozedur TA..ROLLBCKMEM ermöglicht ein Rückgängigmachen (Roll backward) von tranεaktionεgesteuerten Eingaben. Diese Prozedur führt folgende Aktionen durch: - Sie durchschreitet die Weichenstruktur-Kette .einer Transak¬ tion
- Sie veranlaßt den Datenpool VLP im Falle von in der Wei¬ chenstruktur-Kette eingebundenen Speicherblöcken, diese Speicherblöcke freizugeben, - Sie informiert den Funktionskomplex Plattform New der die Tranεaktion anfordernden Modulinεtanz, fallε die Kommando- kennung dem Kommando-Create entsprach, - Sie löst die entsprechende Weichenstruktur auε dem Datenzu¬ griffεpfad herauε,
- Sie εetzt die Einträge im Header deε Tranεaktionsblattes TGL und deε Weichenpoolε TGS.P zurück.
Die Prozedur TA.ROLLBCKMEM wird auch im Falle eines Diskfeh- lerε benützt.
Eine Prozedur TA..ROLLFORWARD ermöglicht ein Fortεetzen (roll forward) von tranεaktionsgeεteuerten Eingaben im Falle von Recovery-Ereigniεεen und beinhaltet hierzu Teile der εpäter erläuterten Prozedur DO_TA. Der Einstiegspunkt in diese be¬ inhaltete Prozedur hängt vom Transaktionsεtatuε ab, der beim Eintritt deε Recovery-Ereigniεεeε vorlag.
Im folgenden werden komplexere Primitiven deε Reεourcen-Mana- gement-Syεtemε RMS anhand der Fig. 10 biε 12 erläutert.
Fig. 10 zeigt ein Flußdiagramm der Prozedur DO_TADATA.
Die Prozedur DO_TADATA veranlaßt, daß dem Zugriffεεteuerungε- εyεte übergebene Tranεaktionsdaten an die Aufdatierungsin- εtanz UPDATE weitergegeben werden, und zwar sowohl zur Ab¬ speicherung in das Notizbuch NOTEBOOK, als auch auf die Plat- te DISK. Ein Eingangsparameter TASK mit den zwei möglichen Werten "TGSLEAF" oder "VLP" bestimmt dabei, ob die Prozedur mit den Transaktionsdaten, die durch den Eintrag im Header des Transaktionεblatteε feεtgelegt εind arbeitet, oder mit denjenigen Tranεaktionεdaten, die in einem entεprechenden Speicherblock im Datenpool VLP abgeεpeichert εind, arbeitet. Mögliche Ausgangsparameter OUTPUT der genannten Prozedur sind "Disk-Error", "NO_SUCCESS" und "SUCCESS".
Fig. 11 εtellt daε Flußdiagramm einer Prozedur DO_HEADER dar. Dieεe Prozedur übergibt die Einträge im Header des Weichen¬ pools, des Transaktionεblattes und des Logbuchs einer Trans¬ aktion an die Aufdatierungsinεtanz mit dem Auftrag zur Ab- speicherung im Notizbuch. Sodann durchläuft die Prozedur die Weichenkette und übergibt die sämtliche Bindungsinformationen enthaltenden Header der Speicherblöcke des Datenpoolε eben- fallε an die Aufdatierungεinεtanz zur Abεpeicherung im Notiz- buch. Auε Konεiεtenzgründen muß diese Prozedur ebenfalls si¬ cherstellen, daß Header-Informationen, die Daten bezüglich Zugriffs-Datenεtrukturen betreffen, in dasselbe Notizbuch eingegeben werden. Falls nötig, muß diese Prozedur außerdem die Aufdatierungsinεtanz mit dem Auftrag zur Abspeicherung auf der Platte DISK aufrufen. Diese Prozedur beinhaltet keine Eingangsparameter, während ihre Ausgangsparameter identisch mit den Ausgangsparametern der Prozedur D0_TADATA sind. Die Prozedur nder darüber hinaus zweimal den Status-Eintrag der Transaktion im Logbuch, und zwar wird beim ersten Mal die Status-Information TA..CLOSED in die Status-Information TA_ TGSHPREP umgewandelt und beim zweiten Mal die Statusinforma¬ tion TA.TGSHPREP in die Statuεinfor ation TA_TGHSUCC umgewan¬ delt, fallε im Verlauf der Prozedur die AufdatierungεInforma¬ tion mit dem Auftrag zur Abεpeicherung auf Platte aufgerufen wurde.
Fig. 12 zeigt daε Flußdiagramm einer Prozedur DO_TGSE_ENTRY. Diese Prozedur durchläuft die Weichenstruktur-Kette und über¬ trägt BindungεInformationen, die eine Weichenεtruktur in den Datenzugriffεpfad einbinden, an die Aufdatierungεinεtanz mit dem Auftrag zur Abεpeicherung im Notizbuch. Fallε nötig, ver¬ anlaßt εie dabei ebenfallε eine Abεpeicherung auf der Platte mit dem Aufruf UPDATE: DISK. Die Prozedur hat keinen Ein- gangεparameter und alε Auεgangεparameter dieεelben Parameter wie die vorhergehende Prozedur. Die Prozedur wandelt darüber hinauε mögliche Statuε-Informationen TA.TGSHPREP bzw. TA_ TGSHSUCC in die Statuε-Information TA_DISKPREP um.
Damit εind die Schnittεtellen-Prozeduren deε Zugriffε-Steue- rungεεystems zu den Modulinεtanzen erläutert. Im folgenden werden die Schnittεtellenprozeduren deε Zugriffs-Steuerungε- syεtemε zum Anwender anhand der Fig. 13 biε 15 näher erläu¬ tert.
Fig. 13 zeigt daε Flußdiagramm einer Prozedur START_TA. Diese Prozedur eröffnet eine Transaktion, wobei sie dem Zugriffε- Steuerungεεyεtem alε Eingangεparameter die Prozeßgruppenken- nung übergibt. Und alε Auεgangεparameter die in Fig. 13 ange¬ gebenen Parameter TA_ID und/oder "LACK OFF RESOURCES" erhält. Die Statuε-Information wird im Verlaufe dieεer Prozedur von "NO.TRANS".
Fig. 14 zeigt daε Flußdiagramm einer Prozedur ABORT.TA. Diese Prozedur ermöglicht es dem Anwender, eine von ihm aktivierte Tranεaktion wieder abzubrechen. Als Eingangsparameter über- gibt der Anwender dem Zugriffsεteuerungεεystem dabei die zu der Transaktion zugehörige Transaktionεkennung, woraufhin die zugehörige Tranεaktion durch die Prozedur rückgängig gemacht wird. Die Ausgangsparameter der Prozedur sind wiederum aus Fig. 14 entnehmbar. Die zu Beginn der Prozedur vorliegenden möglichen Statusinformationen "TA_STARTED" oder "TA.NODISKNB" werden durch die Prozedur in die Statusinformation "TA_ ABORTED" umgewandelt.
Fig. 15 zeigt das Flußdiagramm einer Prozedur DO_TA. Dieεe Prozedur beendet die Vorbereitungsphase und eröffnet die Ak¬ tivierungsphaεe einer Transaktion. Der Eingangsparameter die¬ ser Prozedur ist die Tranεaktionεkennung TA_ID, während die Auεgangεparameter dieεer Prozedur wiederum aus Fig. 15 ent¬ nehmbar sind. Der Status einer Tranεaktion wird durch dieεe Prozedur zweimal geändert. Daε erεte Mal wird die vorliegende Statuεinformation "TA_STARTED" in die Statuε-Information "TA_ CLOSED" umgewandelt. Daε zweite Mal wird die vorliegende Sta¬ tuε-Information "TA-CLOSED" entweder in die Status-Informa¬ tion "TA_DISKSUCC", oder "TA_DISKNOSUCC" oder "TA.NODISKNB" umgewandelt. Im folgenden wird daε Generationen-Management-Syεtem näher erläutert.
Daε Generationen-Management-Syεtem steuert, wie bereits er- wähnt, den leseorientierten Zugriff auf die Datenobjekte des Datenverwaltungsεyεtemε. Der leεeorientierte Zugriff umfaßt dabei eine Sequenz von logisch untereinander verbundenen Le¬ seanforderungen. Innerhalb einer solchen Sequenz ist sicher¬ gestellt, daß auf einen konsistenten Satz von Datenobjekten, d.h. einen Satz von Datenobjekten, der bezüglich eines be¬ stimmten Zeitpunkts gültig ist, zugegriffen wird, und zwar sogar dann, wenn eine Transaktion parallel dazu eine oder mehrere der zugegriffenen Datenobjekte aufdatiert.Um diese Gleichzeitigkeit zu gewährleisten, wird das neue und alte Ab- bild jedes Datenobjekts in paralleler Weise sowohl im Ar- beitεεpeicher wie auch auf der Platte gespeichert. Die Gene¬ rationenkennung GEN-ID, die während der Aktivierungsphase ei¬ ner Transaktion zugeordnet wird, wird vom Generationen-Mana¬ gement-System in der Generationen-Phase einer Transaktion be- nützt, um die von der Transaktion erzeugte neue Datengenera¬ tion in eindeutiger Weise zu identifizieren.
Wenn für ein bestimmteε Datenobjekt mehr alε eine Aufdatie- rung durchgeführt worden iεt, und dabei mehr alε eine alte Datengeneration im Speicher behalten wurde, dann beginnt ein εogenannter Generationenbaum zu wachsen.
Fig. 16 zeigt einen beispielhaften Generationenbaum für ein bestimmteε Datenobjekt. Der Generationenbaum umfaßt drei Ge- nerationen Dl, D2 und D3. Die jüngεte Generation D3 ist in einer Weichenstruktur enthalten, während die älteste Genera¬ tion Dl an ihrer endgültigen Stelle im Arbeitsspeicher vor¬ liegt. Der Datenzugriffspfad zum Generationenbaum ist über eine Übersetzerεtruktur in Form einer Liste realisiert, die im folgenden als Übersetzerliεte TRL bezeichnet wird. Die Re- cordfelder der Übersetzerεtruktur werden vom Zugriffs-Steue- rungs-System über einen logischen Index angesteuert und er- halten einen physikaliεchen Zeiger auf eine Weichenεtruktur bzw. fallε kein Generationenbaum exiεtiert auf daε Datenob¬ jekt im Arbeitεεpeicher zurück. Die Recordfeider der Überset- zerεtruktur werden im weiteren entεprechend ihrer Funktion alε Datenverknüpfungεfeider bezeichnet.
Zum Abbau deε Generationenbaums umfaßt das Generationen-Mana¬ gement-Syεtem TMS (εiehe Fig. 4) ein Transaktionε-Poεt- Processing-System, daε alle im Rahmen einer Tranεaktion im εemipermanenten Weichen-Pool TGS_P gespeicherten Daten (Input-Daten) aus diesem auf ihre endgültigen Speicherstellen im Arbeitεεpeicher und auf der Platte überträgt. Der Start deε Transaktionε-Post-Procesεing-Syεtemε markiert deshalb für die zu diese Daten gehörige Transaktion den Beginn der Gene- rationenphase. Durch das Transaktions-Poεt-Proceεεing-System werden aber gleichzeitig die unter diesen neu eingebrachten Daten liegenden Daten der älteεten Datengeneration endgültig zerstört. Der Start deε Tranεaktions-Post-Proceεεing-Syεtem markiert deεhalb für die zu dieεen Daten gehörige Tranεaktion das Ende der Generationenphase.
Daε Tranεaktionε-Poεt-Proceεεing-Syεtem iεt technisch als ei¬ ne interne Tranεaktion deε Zugriffs-Steuerungε-Systems reali¬ siert und deshalb gegenüber anderen Transaktionen synchroni- εiert und koordiniert.
Daε Tranεaktionε-Poεt-Proceεεing-Syεtem wird auε zwei unter- εchiedlichen Gründen geεtartet und hat deεhalb zwei unter- εchiedliche Prozeεεprioritäten. Wenn daε Transaktions-Post- Processing-System gestartet wird, um einen Mangel an Resour- cen im TGS-Pool zu beheben, hat eε eine höhere Prozeεεpriori- tät alε eine Verwaltungsprozesε. Wenn daε Transaktions-Post- Proceεsing-System geεtartet wird, um die durch eine Transak¬ tion neu eingebrachten Daten auf ihre endgültigen Speicher- platze zu transferieren, hat eε dieεεelbe Prozeεεpriorität wie ein Verwaltungεprozeεs. Fig. 17 zeigt das Flußdiagramm des Transaktionε-Poεt-Proceε- sing-System, wobei darin auftretende Bezeichnungen weiter un¬ ten näher erläutert werden.
Im folgenden werden diejenigen Zugriffs-Datenstrukturen des Resource-Management-Systemε RMS näher erläutert, die aus¬ schließlich dazu dienen, die Aufgaben des Generationen-Mana¬ gement-Systemε zu unterstützen.
Fig. 18 zeigt die im Zuεammenhang mit dem Generationen-Mana¬ gement-System eingeführte Zugriffs-Datenstruktur, das sog. Lese-Logbuch SEQ.LOGBOOK, in dem aktive Lesese uenzen aufge¬ zeichnet werden. Mit Hilfe des Lese-Logbuchε wird εicherge- εtellt, daß ein Datenobjekt, welcheε von einer aktiven Lese- sequenz erreicht wird, vom physikalischen Auslöεchen durch daε Tranεaktions-Post-Proceεεing-Syεtem auεgeschloεεen wird. Daε Leεelogbuch nimmt außerdem an der Zeitüberwachung von Le- εeεequenzen teil, da zu lange laufende Leεeεequenzen einen negativen Systemeinfluß darstellen. Diese Teilnahme besteht darin, daß die Zeitüberwachung die Einträge im Lese-Logbuch zyklisch abscannt. Wenn sie dabei eine Lesesequenz entdeckt, die eine bestimmte Zeitgrenze überεchritten hat, wird dieεe Leεeεequenz verworfen.
Daε Leεelogbuch beinhaltet ein Datenfeld PROCGRP-ID, daε In¬ formationen über die Prozeßgruppe, die die Leεesequenz aufge¬ rufen hat, beinhaltet. Dieses Feld dient, ebenso wie das ent¬ sprechende Feld im Transaktionslogbuch zur Unterstützung des Recovery-Post-Processingε.
Daε Leεelogbuchε umfaßt deε weiteren ein Datenfeld SEQ_ STATUS, daε dem Tranεaktionε-Poεt-Proceεεing-Syεtem eine lau¬ fende aktive Leεeεequenz anzeigt und dadurch auεεchließt, daß eine zu der Generationenkennung zugehöriges Datenobjekt phy- sikaliεch gelόεcht wird. Im folgenden werden diejenigen Resourcenprimitiven des Re- εourcen-Management-Syεtemε näher erläutert, die ausεchließ- lich vom Generationen-Management-Syεtem benutzt werden und ebenfallε wie die Resourcenprimitiven deε Tranεaktions-Mana- gement-Systemε eine Shell um die Zugriffε-Daten-Strukturen deε Resourcen-Management-Systems bilden.
Eine Prozedur VERIFY.GENID verifiziert die Generationskennung
GEN-ID und übermittelt εie dem Generationen-Management-Sy- εtem, das sie in die Bereichεtabelle SKOPE_TABLE abεpeichert.
Eine Prozedur ALLOC_SEQREC ordnet einer Leεeεequenz zu Beginn ein der Generationenkennung entsprechendes Record im Leεelog¬ buch zu.
Eine Prozedur ENTER.SEQLOG überträgt eine Statuε-Information der Leεeεequenz in daε Leselogbuch.
Eine Prozedur DETMINE_GENIDOLD wertet die Bereichstabelle aus und bestimmt die älteste Generationenkennung GEN_ID_OLD.
Eine Prozedur TRANS-GENTAID ermittelt anhand der Bereichsta¬ belle diejenige Transaktionskennung, die zu der dieser Proze¬ dur übergebenen Generationenkennung korrespondiert.
Eine Prozedur POSTPROCTGSE des Transaktionε-Poεt-Proceεεing- Syεtemε TAPP, durchεchreitet die Weichenεtruktur-Kette einer Transaktion und führt dabei folgende Aktivitäten durch:
- Sie führt im Falle eines wenig priorisierten Transaktions- Post-Proceεsings einen Kolliεionεcheck durch, indem εie ei¬ ne Prozedur GEN.CONCTRL deε Kolliεionε-Management-Syεtemε aufruft, die εpäter anhand Fig. 22 näher erläutert wird,
- Sie kopiert den Inhalt einer Weichenstruktur an die endgül¬ tige Speicherstelle im Arbeitεεpeicher, löεt die Weichen- Struktur im Falle eines verknüpften Speicherblocks deε Da- tenpoolε auε dem Datenzugriffspfad und informiert dςn Da¬ tenpool darüber, - Sie überträgt Transaktionsdaten in den Zwischenεpeicher der Tranεaktion und veranlaßt, fallε nötig, einen zwiεchenzeit- lichen Aufdatierungεvorgang,
- Sie datiert den Header deε Tranεaktionsblattes auf und trägt die Weichenstruktur-Nummer NO-TGSE in das Tranεakti- onεlogbuch ein.
Eine Prozedur POSTPROC-HEADER deε Tranεaktionε-Post-Proces- sing-Syεtems, die folgende Aktivitäten umfaßt: - Sie ändert die transiente Status-Information im Header des Weichenpools auf den Wert "TA_CLOSED",
- Sie gibt das Zugangsfeld (Verschlußfeld) zum Header des Weichenpools und zum Transaktionεblatt der Tranεaktion frei, - Sie wechselt die Statuε-Information im Tranεaktionεlogbuch auf den Wert "GEN_DISKPREP" und betritt den entsprechenden Record im Header des Weichenpoolε,
- Sie tranεferiert die Daten im εprechenden Record deε Hea¬ derε deε Weichenpoolε εowie die Daten im Tranεaktionεlog- buch in einen Zwiεchenεpeicher NOTEBOOK(NB) ,
- Sie veranlaßt und εteuert den Aufdatierungεvorgang auf der Platte DISK.
Eine Prozedur GEN-ROLLBCK ermöglicht eine Rückgängigmachung (Roll backward) von Tranεaktionen in der Generationenphaεe und führt dazu folgende Aktionen durch:
Sie durchεchreitet die εemipermanente Weichenεtruktur- Kette,
- Sie wertet die Verknüpfungsdaten zwischen der Weichenεtruk- tur und dem Datenzugriffspfad aus, verknüpft, falls nötig, erneut die Weichenstruktur mit dem Datenzugriffspfad, über¬ trägt die Verknüpfungsdaten in den Zwischenεpeicher, und veranlaßt, fallε notwendig einen zwiεchenzeitlichen Aufda¬ tierungεvorgang auf die Platte, - Sie ruft die Aufdatierungεinεtanz UPDATE zur Veranlaεsung der Aufdatierung auf die Platte auf, - Sie benützt die Prozedur CONFIRM.TADATA, die ebenfalls vom Transaktionε-Management-Syεtem benützt wird und bereitε früher erläutert wurde.
Im folgenden werden die Schnittstellenprozeduren zwischen An¬ wender und Generationen-Management-System anhand der Fig. 19 und 20 näher erläutert.
Fig. 19 zeigt daε Flußdiagramm einer Prozedur BE- GIN_GETSEQUENCE, durch deren Aufruf vom Anwender eine Lese¬ sequenz gestartet wird. Diese Prozedur ordnet der Leseεequenz ein der momentan aktuellen Generationenkennung entεprechendeε Record-Feld im Leεelogbuch zu und ändert den Parameter SE _STATUS auf den Wert "cloεed". Dadurch wird εicherge- εteilt, daß kein Datenobjekt, das zu der aktuellen Generatio¬ nenkennung gehört, durch das Transaction-Poεt-Proceεεing ge- löεcht werden kann. Außerdem wird durch diese Prozedur eine Zeitüberwachung aufgerufen, um einen negativen Systemeinfluß durch eine langlaufende Leseεequenz zu vermeiden. Alε Ein- gangεparameter dieεer Prozedur dient der Parameter PROCGRP_ID. Ausgangsparameter dieser Prozedur sind die Gene¬ rationenkennung GEN_ID, sowie ein Meldungεparameter, der die Meldungen "lack of reεεourceε" und "accepted" umfaßt.
Fig. 20 zeigt daε Flußdiagramm der Prozedur END_GETSEQUENCE, die eine Leεeεequenz beendet und alle zu der Generationenken¬ nung der Leεeεequenz zugehörigen Datenobjekte für daε Trans- aktions-Poεt-Proceεεing freigibt, indem εie den Parameter SEQ_STATUS auf den Wert "FREE" ändert. Eingangεparameter die- εer Prozedur iεt der Parameter GEN_ID. Ausgangsparameter die¬ ser Prozedur ist ein Meldungsparamter mit den Meldungen "Out of scope" oder "accepted" .
Im folgenden wird daε Kollisionε-Management-System näher er- läutert, das Zugriffskonflikte gleichzeitig stattfindender Transaktionen behandelt, die sich nicht, gänzlich durch plane¬ rische Maßnahmen von vornherein vermeiden lassen. Das Kolli- εions-Management-System umfaßt im wesentlichen zwei Prozedu¬ ren, nämlich eine Prozedur TA_CONCTRL, die Zugriffskollisio¬ nen in der vom Transaktions-Management-Syεtem kontrollierten Phaεe einer Transaktion zu behandeln, und eine Prozedur GEN_CONCTRL, die Zugriffεkolliεionen in der vom Generationen- Management-Syεtem kontrollierten Phaεe einer Tranεaktion zu behandeln.
Fig. 21 zeigt ein Flußdiagramm der Prozedur TA_CONCRTL, die in die Prozedur ALLOC_TGSE eingebettet iεt und Zugriffskon¬ flikte in der Vorbereitungsphase einer Transaktion behandelt, wenn zwei Transaktionen ihre Weichenstruktur mit demselben Datenverknüpfungsfeld des Datenzugriffspfadeε zu einem Daten¬ objekt verknüpfen wollen. Um dieεe Konfliktεituation zu lö- εen, beinhaltet ein Datenverknüpfungεfeld (data link field) außer dem Zeigerfeld ein Zugangεfeld, in dem eine Transaktion seine Transaktionskennung hinterlegt, falls das Zugangsfeld noch nicht verschloεεen iεt, d.h. fallε keine andere Transak¬ tionskennung in dem Zugangsfeld bereits hinterlegt ist. Die Verknüpfung der Weichenstruktur mit dem Datenzugriffspfad wird daraufhin durch die Hinterlegung des physikaliεchen Zei- gerε auf die Weichenεtruktur bewirkt. Eine Weichenεtruktur, die im Rahmen einer Transaktion mit einem bestimmten Daten¬ verknüpfungεfeld verknüpft werden εoll, gerät in einen Kolli- εionεkonflikt, fallε eine andere aktive Tranεaktion das Zu¬ gangεfeld dieseε Datenverknüpfungsfeldes bereits besetzt hat. Die Koordination dieseε Konfliktes wird wie folgt geregelt:
- eine Transaktion in der Vorbereitungεphaεe, die ein Zu- gangεfeld zu einem Datenobjekt zuerεt reεerviert hat, dar¬ auf fortgeführt werden. Die andere Tranεaktion wird verwor¬ fen.
- Eine Tranεaktion, die die Aktivierungεphaεe bereitε er¬ reicht hat, wird wegen Zugriffεkonflikten nicht mehr ver- worfen. Fig. 22 zeigt ein Flußdiagramm der Prozedur GEN_CONCTRL, die in die Prozedur POSTPROCR_TGSE deε Tranεaktionε-Poεt-Proceε- εing-Syεtemε eingebettet iεt und Konflikte zwiεchen Transak- tions-Poεt-Proceεεing-System und einer Leseεequenz in der Ge- nerationenphase einer Transaktion behandelt. Genauer gesagt verhindert die Prozedur GEN_CONCTRL im Falle eineε gering prioriεierten Transaktions-Post-Proceεεingε, daß eine Daten¬ generation gelöεcht wird, wenn eine Leεeεequenz auf dieεe Da¬ tengeneration zugreifen will. Im Gegenεatz dazu wird bei ei- nem hochprioriεierten Tranεaktionε-Poεt-Proceεεingε, daε im Falle eineε Mangelε an Reεεourcen für daε Zugriffsεteuerungε- εystem durchgeführt wird, die Leseεequenz verworfen und die Datengeneration gelöεcht.
Im folgenden werden die in einer Tranεaktion oder einer Leεe¬ εequenz zuεammengefaßten Einzelaktionen bzw. genauer gesagt die Prozeduren zur Durchführung dieser Einzelaktionen anhand der Fig. 23, 24 und 25 näher erläutert.
Fig. 23 zeigt eine Prozedur GET, die in einem Anwendermodul enthalten ist und eine einzelne Leseaktion durchführt, wobei εie εowohl im Rahmen einer Tranεaktion, als auch im Rahmen einer Leseεequenz aufgerufen werden kann. Eingangεparameter der Prozedur GET εind eine Kennung der Leseaktion und ein lo- gischer Key, der durch den Datenzugriffspfad zum Datenobjekt führt. Bei der Kennung der Transaktion handelt es sich um ei¬ ne Transaktionskennung TA_ID, wenn die Prozedur GET innerhalb einer Transaktion verwendet wird. Im anderen Fall, nämlich wenn die Prozedur GET innerhalb einer Leseεequenz verwendet wird, handelt es sich bei der Kennung um eine Generationen¬ kennung GEN_ID. Auεgangεparameter der Prozedur GET εind daε Datenobjekt εowie ein Meldungεparameter zur Rückgabe von Kon- trollmeldungen.
Zunächst wird anhand des logischen Keys über Listen der Da¬ tenzugriffspfad durchlaufen. Fig. 24 zeigt die beispielhafte Struktur eineε Datenzugriffs- pfads, der mehrere Listen umfaßt und im anwenderunabhängigen Datenmodul VLP abgespeichert iεt. Der Datenzugriffεpfad um¬ faßt eine Datenblockliεte UBL, deren Liεtenelemente Zeiger auf Datenblöcke ÜB darεtellen, sowie innerhalb eines Daten¬ blocks ÜB eine Objektklasεenliεte OCL und Datenobjektliεten DOL . Der logiεche Key umfaßt Indexe der genannten Listen, nämlich die Indexe UBL_IX, OCL_IX und DOL_IX, anhand derer schließlich der Zeiger auf ein Datenobjekt OCI bzw. eine Wei- chenstruktur TGSE ermittelt werden kann.
Zunächεt durchläuft die Prozedur GET den Datenzugriffspfad, indem sie die Prozedur RD_BLK aufruft, die im anwenderunab¬ hängigen zentralen Datenpool VLP implementiert ist. Diese Prozedur liefert als Rückgabewert den physikalischen Zeiger auf eine Datenobjektsliεte DOL. Im Falle einer Transaktion wird dieser Zeiger erst in der auf die Vorbereitungsphase der Transaktion folgenden Aktivierungsphase benutzt, um den ei¬ gentlichen Zugriff auεzuführen.
Alε nächεtes wird die Prozedur ACCESS_OCI mit den Parametern "Zeiger auf die Datenobjektliεte DOL" und "DOL_IX" aufgeru¬ fen. Dieεe Prozedur untersucht u.a. den Header der DOL und ermittelt, ob es εich bei dem übergebenen Parameter "DOL_IX" um einen gültigen Index handelt.
Iεt der Index DOL_IX gültig, dann wird anεchließend das dem Index DOL_IX entsprechende Listenfeld der Liste DOL analy¬ siert. Dabei wird unterεucht, ob eε sich bei der im Zugangs- feld (Verschlußfeld) des Listenfeldeε abgeεpeicherten Kennung ID um eine Tranεaktionεkennung oder eine Generationenkennung handelt. Dieε ist in Fig. 23 durch einen Verzweigungsblock dargestellt.
Falls eε εich um eine Generationenkennung handelt wird anhand der Prozedur EVAL_GENTREE der εich an den Datenzugriffεpfad anεchließende Generationenbaum ausgewertet und daraufhin der der Generationenkennung entεprechende phyεikaliεche Zeiger auf das Datenobjekt zurückgegeben.
Falls eε εich bei der Kennung ID um eine Tranεaktionεkennung handelt, wird die Prozedur ALLOC_TGSE aufgerufen, die eine darauffolgende Schreibaktion durch eine Prozedur SET vorbe¬ reitet, und daε Datenobjekt gegenüber anderen Tranεaktionen verεchloεεen. Dieε hat deεweiteren zur Folge, daß während der Aktivierungεphaεe der Tranεaktion daε Tranεaktionε-Poεt- Proceεεing keine Aktionen bezüglich dieεes Datenobjekts durchführen kann.
Ein anwenderspezifiεcheε Datenmodule GMI umfaßt deεweiteren eine Prozedur SET, die ein Datenobjekt innerhalb einer Trans- aktion modifiziert. Eingangεparameter dieεer Prozedur εind eine Tranεaktionεkennung TA_ID, ein logiεcher Key zur Führung durch den Datenzugriffεpfad und ein Zeiger zu den neu zu übernehmenden Daten εowie eine Längenangabe der neuen Daten. Ausgangsparameter iεt ein Parameter für Rückmeldungen.
Die Prozedur SET umfaßt wie die Prozedur GET den Datenzugang, der mit Hilfe der Prozeduren RD_BLK und ACCESS_OCI durchge¬ führt wird. Danach wird die im CTCC enthaltene Prozedur ALLOC_TGSE aufgerufen, die eine neue Weichenεtruktur TGSE anfordert und die neuen Daten bzw. daε neue Datenobjekt in die Weichenεtruktur kopiert. Fallε die Prozedur SET durch die Prozedur GET vorbereitet wurde, entfällt die genannte Zuord¬ nung einer neuen Weichenεtruktur.
Die anwenderεpezifiεchen Datenmodule umfaεεen desweiteren ei¬ ne Prozedur CREATE, die eine Objektklasse um ein Datenobjekt erweitert und eine Prozedur DELETE, die eine Objektklasse um ein Datenobjekt verringert. Die beiden genannten Prozeduren sind für die Beschreibung der Erfindung ohne Bedeutung und werden deshalb nicht näher erläutert.

Claims

Patentanεprüche
1. Datenverwaltungεεyεtem eineε Realzeitεyεtemε, mit a) einem Tranεaktions-Management-System (TMS) , daε Tranεak- tionen zwiεchen Anwendern und Datenverwaltungεεyεtem εteuert, wobei eε sich bei einer Transaktion um eine Se¬ quenz von Zugriffen auf logiεch voneinander abhängige Da¬ ten handelt b) einer Zugriffε-Datenεtruktur (TGSE) , die vom Tranεaktionε- Management-Syεtem im Rahmen einer Tranεaktion in den Zu¬ griffspfad eines zu modifizierenden Datenobjekts eingefügt wird, und die eine Weiche mit einem ersten Auεgang zum al¬ ten Abbild des Datenobjekts und einem zweiten Ausgang zum neuen Abbild deε Datenobjektε umfaßt, c) einem Generationen-Management-Syεtem (GMS) , daε die im Rahmen einer Tranεaktion erzeugte neue Datengeneration nach der Beendigung der Transaktion anhand der durch die Transaktion eingefügten Zugriffs-Datenstrukturen(TGSE) verwaltet.
2. Datenverwaltungsεyεtem eineε Realzeitεyεtemε nach Anεpruch
1 , gekennzeichnet durch eine Verwaltungε-Datenεtruktur (TGL) , mithilfe derer daε Transaktionε-Management-System die im Rahmen einer Tranεak¬ tion eingefügten Zugriffε-Datenεtrukturen (TGSE) durch Ver¬ kettung zu einer Datengeneration mit einer beεtimmten Genera¬ tionenkennung (GEN_ID) zuεammenfaßt, wobei die Generationen¬ kennung dem Generationen-Management-Syεtem anεchließend zur Verwaltung der εolchermaßen zuεammengefaßten Datengeneration übergeben wird.
3. Datenverwaltungεεyεtem eineε Realzeitsystems nach Anspruch 1 oder 2, dadurch gekennzeichnet , daß das Generationen-Management-System ein Lese-Management- System (LMS) umfaßt, das logiεch zuεammenhängende Leεezu- griffe, εogenannte Leεeεequenzen εteuert, wobei daε LMS die an das Generationen-Managemen -System übergebenen Generatio¬ nenkennung (GEN_ID) benützt, um einen konsiεtenten Lesese- quenzzugriff durchzuführen.
4. Datenverwaltungssystem eines Realzeitsyεtemε nach einem der Anεprüche 1 biε 3, dadurch gekennzeichnet , daß die Zugriffε-Datenεtruktur (TGSE) ein Verεchlußfeld (TA_ID) umfaßt, mithilfe deεεen eine Tranεaktion den Zugang zu einem dahinterliegenden Datenobjekt durch Hinterlegung ei¬ ner Tranεaktionεkennung (TA_ID) auεεchließlich für εich re- εervieren kann.
5. Datenverwaltungssyεtem eineε Realzeitεyεtemε nach einem der Anεprüche 1 biε 4, dadurch gekennzeichnet, daß die Zugriffε-Datenεtruktur (TGSE) den Datenobjekten dyna- miεch zugeordnet werden.
6. Datenverwaltungεεyεtem eines Realzeitεyεtems nach Anspruch
5, dadurch gekennzeichnet , daß das Datenlayout einer Zugriffε-Datenεtruktur (TGSE) der- art ausgebildet ist, daß der erste Auεgang. der Weiche einer
Zugriffs-Datenεtruktur (TGSE) auch auf eine ältere Zugriffs-
Datenstruktur (TGSE) zeigen kann.
PCT/DE1995/000583 1994-05-10 1995-05-03 Datenverwaltungssystem eines realzeitsystems WO1995030955A1 (de)

Priority Applications (4)

Application Number Priority Date Filing Date Title
EP95916579A EP0760130B1 (de) 1994-05-10 1995-05-03 Datenverwaltungssystem eines realzeitsystems
JP7528595A JPH09505681A (ja) 1994-05-10 1995-05-03 リアルタイムシステムにおけるデータ管理システム
DE59501924T DE59501924D1 (de) 1994-05-10 1995-05-03 Datenverwaltungssystem eines realzeitsystems
US08/737,044 US6662202B1 (en) 1994-05-10 1995-05-03 Data management system of a real-time system

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
DEP4416552.8 1994-05-10
DE4416552 1994-05-10

Publications (1)

Publication Number Publication Date
WO1995030955A1 true WO1995030955A1 (de) 1995-11-16

Family

ID=6517820

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/DE1995/000583 WO1995030955A1 (de) 1994-05-10 1995-05-03 Datenverwaltungssystem eines realzeitsystems

Country Status (8)

Country Link
US (1) US6662202B1 (de)
EP (1) EP0760130B1 (de)
JP (1) JPH09505681A (de)
CN (1) CN1149479C (de)
AT (1) ATE165174T1 (de)
DE (1) DE59501924D1 (de)
ES (1) ES2116745T3 (de)
WO (1) WO1995030955A1 (de)

Families Citing this family (36)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7490325B2 (en) 2004-03-13 2009-02-10 Cluster Resources, Inc. System and method for providing intelligent pre-staging of data in a compute environment
US7971204B2 (en) 2004-03-13 2011-06-28 Adaptive Computing Enterprises, Inc. System and method of co-allocating a reservation spanning different compute resources types
US8782654B2 (en) 2004-03-13 2014-07-15 Adaptive Computing Enterprises, Inc. Co-allocating a reservation spanning different compute resources types
US7620706B2 (en) 2004-03-13 2009-11-17 Adaptive Computing Enterprises Inc. System and method for providing advanced reservations in a compute environment
US20070266388A1 (en) 2004-06-18 2007-11-15 Cluster Resources, Inc. System and method for providing advanced reservations in a compute environment
US8176490B1 (en) 2004-08-20 2012-05-08 Adaptive Computing Enterprises, Inc. System and method of interfacing a workload manager and scheduler with an identity manager
CA2586763C (en) 2004-11-08 2013-12-17 Cluster Resources, Inc. System and method of providing system jobs within a compute environment
US8863143B2 (en) 2006-03-16 2014-10-14 Adaptive Computing Enterprises, Inc. System and method for managing a hybrid compute environment
US7996455B2 (en) 2005-06-17 2011-08-09 Adaptive Computing Enterprises, Inc. System and method for providing dynamic roll-back reservations in time
US7921425B2 (en) * 2005-03-14 2011-04-05 Cisco Technology, Inc. Techniques for allocating computing resources to applications in an embedded system
US9231886B2 (en) 2005-03-16 2016-01-05 Adaptive Computing Enterprises, Inc. Simple integration of an on-demand compute environment
CA2603577A1 (en) 2005-04-07 2006-10-12 Cluster Resources, Inc. On-demand access to compute resources
US8041773B2 (en) 2007-09-24 2011-10-18 The Research Foundation Of State University Of New York Automatic clustering for self-organizing grids
US8484115B2 (en) 2007-10-03 2013-07-09 Palantir Technologies, Inc. Object-oriented time series generator
US10747952B2 (en) 2008-09-15 2020-08-18 Palantir Technologies, Inc. Automatic creation and server push of multiple distinct drafts
US8041714B2 (en) * 2008-09-15 2011-10-18 Palantir Technologies, Inc. Filter chains with associated views for exploring large data sets
US20100070426A1 (en) 2008-09-15 2010-03-18 Palantir Technologies, Inc. Object modeling for exploring large data sets
CN102004745B (zh) * 2009-09-02 2013-06-12 中国银联股份有限公司 数据转移系统及方法
US11720290B2 (en) 2009-10-30 2023-08-08 Iii Holdings 2, Llc Memcached server functionality in a cluster of data processing nodes
US10877695B2 (en) 2009-10-30 2020-12-29 Iii Holdings 2, Llc Memcached server functionality in a cluster of data processing nodes
US8732574B2 (en) 2011-08-25 2014-05-20 Palantir Technologies, Inc. System and method for parameterizing documents for automatic workflow generation
US20130173427A1 (en) * 2012-01-03 2013-07-04 Advanced E-Commerce Research Systems, Inc. Apparatus and method of data sharing between online marketplaces
US9870384B2 (en) 2012-03-30 2018-01-16 International Business Machines Corporation Database system transaction management
US9348677B2 (en) 2012-10-22 2016-05-24 Palantir Technologies Inc. System and method for batch evaluation programs
US8855999B1 (en) 2013-03-15 2014-10-07 Palantir Technologies Inc. Method and system for generating a parser and parsing complex data
US8909656B2 (en) 2013-03-15 2014-12-09 Palantir Technologies Inc. Filter chains with associated multipath views for exploring large data sets
US8868486B2 (en) 2013-03-15 2014-10-21 Palantir Technologies Inc. Time-sensitive cube
US8930897B2 (en) 2013-03-15 2015-01-06 Palantir Technologies Inc. Data integration tool
US8903717B2 (en) 2013-03-15 2014-12-02 Palantir Technologies Inc. Method and system for generating a parser and parsing complex data
US9870543B2 (en) 2013-08-12 2018-01-16 GoodData Corporation Custom-branded analytic applications in a multi-tenant environment
US8938686B1 (en) 2013-10-03 2015-01-20 Palantir Technologies Inc. Systems and methods for analyzing performance of an entity
US9105000B1 (en) 2013-12-10 2015-08-11 Palantir Technologies Inc. Aggregating data from a plurality of data sources
US9286329B2 (en) * 2014-01-31 2016-03-15 GoodData Corporation Generating analytics application using reusable application modules
US8935201B1 (en) 2014-03-18 2015-01-13 Palantir Technologies Inc. Determining and extracting changed data from a data source
CN108090137B (zh) * 2017-11-29 2021-11-26 四川巧夺天工信息安全智能设备有限公司 一种解析edb数据库源文件中过长字段的方法
CN107992561A (zh) * 2017-11-29 2018-05-04 四川巧夺天工信息安全智能设备有限公司 一种解析edb数据库源文件中过长字段的方法

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0266505A2 (de) * 1986-09-11 1988-05-11 International Business Machines Corporation Versionierung von Nachrichtenformaten in einer 24-Stunden-Betriebsumgebung

Family Cites Families (17)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4627019A (en) * 1982-07-08 1986-12-02 At&T Bell Laboratories Database management system for controlling concurrent access to a database
US5027316A (en) * 1986-09-11 1991-06-25 International Business Machines Corporation Versioning of message formats in a 24-hour operating environment
US4809170A (en) * 1987-04-22 1989-02-28 Apollo Computer, Inc. Computer device for aiding in the development of software system
US5179703A (en) * 1987-11-17 1993-01-12 International Business Machines Corporation Dynamically adaptive environment for computer programs
US5043876A (en) * 1988-05-27 1991-08-27 International Business Machines Corporation N-level file shadowing and recovery in a shared file system
JPH03296838A (ja) * 1990-04-17 1991-12-27 Toshiba Corp 履歴データ管理方式
JPH0457127A (ja) * 1990-06-27 1992-02-24 Toshiba Corp 版管理装置
US5440730A (en) * 1990-08-09 1995-08-08 Bell Communications Research, Inc. Time index access structure for temporal databases having concurrent multiple versions
JPH04168569A (ja) * 1990-10-31 1992-06-16 Chubu Nippon Denki Software Kk 文書ファイルの世代管理方式
US5278979A (en) * 1990-12-20 1994-01-11 International Business Machines Corp. Version management system using pointers shared by a plurality of versions for indicating active lines of a version
US5287496A (en) * 1991-02-25 1994-02-15 International Business Machines Corporation Dynamic, finite versioning for concurrent transaction and query processing
JP2828354B2 (ja) * 1991-05-14 1998-11-25 ピー・シー・エー株式会社 データベース管理装置
US5280612A (en) * 1991-11-26 1994-01-18 International Business Machines Corporation Multiple version database concurrency control system
JPH0619769A (ja) * 1992-06-30 1994-01-28 Oki Electric Ind Co Ltd レコードロック制御方法
US5410703A (en) * 1992-07-01 1995-04-25 Telefonaktiebolaget L M Ericsson System for changing software during computer operation
US5687363A (en) * 1994-03-30 1997-11-11 Siemens Stromberg-Carlson Distributed database architecture and distributed database management system for open network evolution
US5682533A (en) * 1994-09-27 1997-10-28 Telefonaktiebolaget Lm Ericsson (Publ) Updating software within a telecommunications switch without interrupting existing communication and neither moving nor converting data

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0266505A2 (de) * 1986-09-11 1988-05-11 International Business Machines Corporation Versionierung von Nachrichtenformaten in einer 24-Stunden-Betriebsumgebung

Non-Patent Citations (4)

* Cited by examiner, † Cited by third party
Title
C. MOHAN ET AL: "Efficient and flexible methods for transient versioning of records to avoid locking by read-only transactions", SIGMOD RECORD, NEW YORK, US, pages 124 - 133 *
CAREY M J ET AL: "The performance of multiversion concurrency control algorithms", ACM TRANSACTIONS ON COMPUTER SYSTEMS, NOV. 1986, USA, vol. 4, no. 4, ISSN 0734-2071, pages 338 - 378 *
CHEN R C ET AL: "IMPLEMENTING CONSISTENCY CONTROL MECHANISMS IN THE CLOUDS DISTRIBUTED OPERATING SYSTEM*", INTERNATIONAL CONFERENCE ON DISTRIBUTED COMPUTING SYSTEMS, ARLINGTON, TEXAS, MAY 20 - 24, 1991, no. CONF. 11, 20 May 1991 (1991-05-20), INSTITUTE OF ELECTRICAL AND ELECTRONICS ENGINEERS, pages 10 - 17, XP000221838 *
KIM W ET AL: "Object-oriented database support for CAD", COMPUTER AIDED DESIGN, OCT. 1990, UK, vol. 22, no. 8, ISSN 0010-4485, pages 469 - 479 *

Also Published As

Publication number Publication date
CN1151796A (zh) 1997-06-11
CN1149479C (zh) 2004-05-12
EP0760130B1 (de) 1998-04-15
DE59501924D1 (de) 1998-05-20
EP0760130A1 (de) 1997-03-05
US6662202B1 (en) 2003-12-09
ES2116745T3 (es) 1998-07-16
ATE165174T1 (de) 1998-05-15
JPH09505681A (ja) 1997-06-03

Similar Documents

Publication Publication Date Title
WO1995030955A1 (de) Datenverwaltungssystem eines realzeitsystems
WO1995030959A1 (de) Datenverwaltungssystem
DE4216871C2 (de) Ausführungsordnen zum Sicherstellen der Serialisierbarkeit verteilter Transaktionen
EP0929864B1 (de) Koordinations-system
DE69628965T2 (de) Verfahren und Gerät zum Verwalten von Beziehungen zwischen Objekten in einer verteilten Objektumgebung
DE69838756T2 (de) Die verarbeitung von eingabe/ausgabeanforderungen von mehreren treibern ermöglichen dateisystem-primitivroutine in einem mehrschicht-treiber-e/a-system
DE69822541T2 (de) Verfahren zum Verwalten eines geteilten Speichers
DE69533786T2 (de) Vorrichtung zum Erzeugen von objektorientierten Schnittstellen für relationale Datenbanken und von dieser Vorrichtung durchgeführtes Verfahren
WO2001027806A1 (de) Integriertes datenbank-verbundsystem
EP0743595B1 (de) Kommunikationssystem mit Mitteln zum Austausch von Software
DE19513308A1 (de) Dreidimensionales Dateisystem unter Verwendung einer virtuellen Knotenarchitektur
EP0635792B1 (de) Verfahren zur Koordination von parallelen Zugriffen mehrerer Prozessoren auf Resourcenkonfigurationen
DE19705955A1 (de) Verfahren zum Generieren einer Implementierung eines Workflow-Prozessmodells in einer Objektumgebung
EP1088280A1 (de) Verfahren und system zur schnellen speicherresidenten verarbeitung von transaktionsdaten
DE19628168A1 (de) Vernetztes multimediales Netz
DE10112941A1 (de) System und Verfahren für das parallele Lesen von primären und sekundären Sicherungen zur Wiederherstellung mehrerer gemeinsam benutzter Datenbankdateien
EP0862123A2 (de) Verfahren zur Regelung eines Zugriffs von Rechnern auf Daten eines zentralen Rechners
DE10128883A1 (de) Verfahren und System für die Verteilung von Anwendungsdaten auf verteilte Datenbanken mit verschiedenen Formaten
DE60009548T2 (de) Verfahren und vorrichtung um objektorientierte daten zu persistieren
EP0303869A1 (de) Modular strukturiertes digitales Kommunikationssystem mit betriebstechnischen Kommunikationsmitteln
DE10209803A1 (de) Verfahren und Vorrichtung zum Liefern eines Dateisystemzugriffs auf ein Plattenarray
DE19910536A1 (de) Automatisierungssystem mit aus Modulkomponenten bestehenden Automatisierungsobjekten
EP1044409B1 (de) Programmablaufverfahren und verfahren zur erweiterung eines programmkomponentensystems
WO2005104018A2 (de) Verwalten eines dateisystems in einem tragbaren datenträger
EP0684574A2 (de) Verfahren und Service-Personalcomputer zum Administrieren und Warten von Kommunikationssystemen

Legal Events

Date Code Title Description
WWE Wipo information: entry into national phase

Ref document number: 95193916.5

Country of ref document: CN

AK Designated states

Kind code of ref document: A1

Designated state(s): CN JP US

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): AT BE CH DE DK ES FR GB GR IE IT LU MC NL PT SE

DFPE Request for preliminary examination filed prior to expiration of 19th month from priority date (pct application filed before 20040101)
121 Ep: the epo has been informed by wipo that ep was designated in this application
WWE Wipo information: entry into national phase

Ref document number: 1995916579

Country of ref document: EP

WWE Wipo information: entry into national phase

Ref document number: 08737044

Country of ref document: US

WWP Wipo information: published in national office

Ref document number: 1995916579

Country of ref document: EP

WWG Wipo information: grant in national office

Ref document number: 1995916579

Country of ref document: EP